>> [MUSIC SPILLE]
>> ABBY FICHTNER: Hei, jeg er Abby Fichtner.
De fleste kjenner meg som Hacker Chick, fordi jeg gjør det Hacker Chick
Blogg om hvordan å bygge bedre teknologi.
Og jeg er også over på Harvard Innovation Labs.
Vet du det Innovation Lab?
OK, så det er ond moro.
Jeg er hacker i bolig der, hvor min rolle
er å hjelpe elevene gjøre alt fra hacking på kjølige sideprosjekter, alt
helt opp til start tech startups.
>> Jeg er en programmerer, så det er min bakgrunn.
Jeg slags fikk inn programmering og oppstarter av en interessant ruten.
Da jeg var på skolen, jeg ønsket å være en ledelseskonsulent,
fordi jeg trodde at ville være dritt.
Jeg vet ikke om det er fortsatt en ting.
Trenger elevene fortsatt ønsker å være konsulenter?
Oppfattes det som virkelig kult?
>> OK, så jeg trodde det var kult.
Jeg fikk jobb med en av toppen management consulting
bedrifter rett ut av skolen.
Jeg var veldig spent rett opp før jeg begynte å jobbe der,
og deretter absolutt hatet det.
Jeg liker ikke selskapet.
Jeg liker ikke kulturen.
>> Jeg liker ikke noe om det bortsett fra at de er veldig snodig
sette meg i programmering, som var veldig rart, fordi min tittel var ikke
programmerer.
Det var ingenting som jeg kan husker i intervjuet om,
du kommer til å bli programmering.
Jeg trodde jeg skulle være rådgivning ledere, uansett hva det betyr.
Jeg er fortsatt faktisk ikke sikker på, men det var fornuftig for meg på den tiden.
>> Så jeg går der, og de faktisk ga meg et kontor,
som var kult, fordi jeg tror det er den eneste jobben jeg noensinne
hadde der jeg hadde et kontor.
Og de ga meg en datamaskin og denne store utstyr som datamaskinen ble hektet
opp til, å så ble jeg skrive kode styre dette utstyret, som var veldig ryddig.
Og at en del jeg faktisk likte.
>> Og jeg gjorde kode for NSA, som var veldig rart.
Det var min første jobb ute av college.
Og så jeg skriver denne koden.
Jeg er bare helt hacking, fordi jeg har ingen anelse om hva
Jeg gjør, og prøver å gjøre det gjøre ting.
>> Og jeg kommer til dette punktet hvor jeg bruker biblioteker for å kontrollere dette utstyret.
Og jeg kan bare gjøre hva som er i bibliotekene,
og ting som jeg må gjøre, det ikke er noen funksjoner for.
Og jeg er like, OK.
Men det var en støtte nummer, så jeg ringe opp
selskapet som skapte programvaren, og jeg sa at jeg trenger å gjøre dette.
Og de var som, ja, kan du ikke gjøre det.
Og det var min første jobb ut av skole og mitt første prosjekt,
og jeg bare føler ikke at jeg kunne bare gå til sjefen og være like--
og han gjorde bare slags av sette meg på min egen.
>> Jeg hadde egentlig ikke lyst til Jeg kunne gå til sjefen
å være som, oh, gå fortelle NSA beklager, vi kommer ikke til å gjøre dette for dem,
fordi biblioteket er ikke tilgjengelig.
Det synes hadde ikke akseptabelt.
Og så jeg slags oppholdt opp hele natt hacking noe sammen,
og jeg gjorde det fungerer.
>> Og det var dette dreiemoment for meg, hvor det bare klikket.
Og jeg innså at dette er hva jeg ønsket å gjøre.
Jeg trodde det var den kuleste tingen noensinne, at jeg var som jeg gjorde noe
at skaperne av programvaren Tanken var ikke engang mulig.
Og jeg var muligens den første personen noensinne til å gjøre dette, ikke sant?
Og det var ikke så stor av en ting, men det var bare en kul idé.
>> Og så jeg forlot den store ledelse konsulentfirma,
og jeg gikk på jobb for startups, fordi startups er alle
om å skape ting som ingen har noensinne er laget før.
Og jeg trodde det var den mest utrolige ting noensinne.
Så jeg gjorde det for et nummer år, type bygget ut
teknologien for startups.
Og da jeg slags, som jeg var sa før, kom inn i dette området
hvor jeg bare går rundt å hjelpe hackere og tech entreprenører som
bygger innovative, forstyrrende products-- hjelpe dem
å gjøre det og finne måter å gjøre det som de
kan lykkes i markedet.
>> Så det er hva jeg vil snakke med dere om i dag.
Så for meg, jeg tror det er en virkelig spennende tid å være i dette rommet
akkurat nå, er fordi teknologi utvide på dette utrolig hastighet,
og det er å gjøre alle disse muligheter
det var aldri tilgjengelig før.
Så jeg føler at vi er tilbake til det punkt, hvor du kan lage ting
at ingen noensinne er laget før.
Og spesielt, du ser på ting som 3D-utskrift.
Slik at folk er 3D-utskrift ting som menneskelige organer eller mat.
NASA har startet 3D utskrift mat astronauter,
så dette er en 3D-printer med deigen og pizza saus
og ost som sine patroner, i stedet for polymerer.
>> Og biler.
Urbee 3D trykt verdens billigste og mest drivstoffeffektive bil,
og de er i ferd med å kjøre det over hele landet
på under 10 liter drivstoff, noe som er ganske sprø.
Og selvfølgelig, alt som skjer med mobil, og det faktum med ting
som 3D-utskrift gjør skape fysiske enheter så mye billigere
har ført til internett av ting, som er denne forestillingen om at hei, hvorfor gjør vi
må ha funksjonaliteten i våre datamaskiner og våre tabletter?
Hvorfor ikke vi ta det ut av dem og faktisk
sendte ballen inn i enheter, hvor vi bryr oss om.
>> Og så vi får ting like-- David Rose
over på Media Lab opprettet en paraply som forteller været.
Og så du kan forestille deg det i en paraply stå ved døren.
Og som den oppdager du går forbi det, hvis det kommer til å regne, vil det blinke,
slik at du vet å ta den med deg.
Eller Valour opprettet en sykkel som gir deg retninger og gir deg
alle dine ride statistikk.
>> Eller Hapi opprettet en gaffel som overvåker matvaner
for å hjelpe deg å spise mer sunt.
Og alt fra selv kjøring biler til mind-kontrollerte helicopters--
>> [Ler LITT]
>> Selv ting som vi trodde på som svært low-tech, som å lese nyhetene.
Gannett nettopp annonsert at de jobber med virtuell virkelighet
journalistikk, hvor du absorbere nyhetene ikke ved å lese den,
men ved faktisk opplever det og være en del av det.
Eller andre ting som vi kanskje tror på som low-tech, som hagearbeid,
fordi du trenger å de-stress.
Fordi jeg vet ikke om dere, men jeg
ville finne leve nyheter å være svært stressende.
>> [Ler]
>> Et team av MIT, Grove, har opprettet en produsere apparatet
som faktisk, kan du sette inn din kjøkkenet for å dyrke frukt og grønnsaker.
Og så det er veldig kult ser på alle de startups.
Det er nettopp denne fantastiske antall oppstarter
som er ute i disse dager som prøver å ta
nytte av disse teknologiene.
Og hva som egentlig interesting-- bare ser på alle disse tingene som er
kommer opp, men bare en meget realisere liten andel av disse startups er
faktisk kommer til å gjøre det inn i fremtiden,
og hva slags forstå hvorfor noen av dem gjøre det, og noen av dem ikke.
>> Så holdt jeg en tale forrige måned ved en teknisk konferanse,
og jeg ønsket å snakke med dem om dette emnet.
Og jeg tenkte at de er ingeniører.
De ønsker regler.
Liker, jeg er en ingeniør.
Jeg liker regler.
Det er veldig fint og ryddig, ikke sant?
Så jeg prøvde å komme opp med reglene for innovasjon.
>> Og så snart jeg gjorde det, jeg innså det er litt dumt.
Den første regelen av innovasjon er at det er ingen regler for innovasjon.
Fordi hvis du gjør det rett, så er du
bryte flere regler enn følgende din.
Og, selvfølgelig, Thomas Edison famously sa at "jeg ikke har mislyktes.
Jeg har nettopp funnet 10.000 måter som ikke vil fungere. "
Og så, selvfølgelig, jo mer nyskapende at du blir,
du trenger å slags forvente at du kommer
å finne flere måter som ikke fungerer.
Men den gode nyheten er at det er ikke en fullstendig svart hull.
Når du ser på startups som har vært vellykket,
innovatørene som har bygget disse produktene som
har vært vellykket i markeder, hva du vil se
er gang på gang, det samme mønstre dukker opp av de tingene
at de gjør.
Og en rekke av disse, når slags grave ned i dem,
de er slags betinget av en rekke prinsippene bak Lean og Agile--
og folk bare tar de og sa: hvordan kan disse være fornuftig for en oppstart?
>> Så jeg ønsker å gå gjennom disse.
For å være ærlig, tror jeg jeg ville liker å tilbringe omtrent halvparten
tiden på denne siste one-- dette "Fokus!
Og få dritt gjort. "
Fordi egentlig, det er hva det kommer ned til.
Men jeg tror de fire første er veldig viktig å forstå
kontekst og tankesett som du trenger
å inngå når du gjør noe virkelig nyskapende at
har ikke blitt gjort før.
>> Så det første prinsippet er eliminere avfall,
som, hvis du vet noe om Lean prinsipper,
det er en av de viktigste prinsippene i Lean.
Og, faktisk, Eric Ries, er hvem skaperen av Lean oppstart
metodikk, sier nummer én Det viktigste for en oppstart
er å lære å se forskjell mellom verdi og waste--
som er ganske rart, ikke sant?
Som hvordan kunne du ikke vite hva er verdi og hva som er avfall?
>> Men jeg tror det er mer fornuftig hvis du tenker på røttene av Lean.
Så Lean kommer fra Lean produksjon Toyota Production System i Japan.
Og "avfall" er en oversettelse fra Uttrykket "muda", som faktisk er bredere.
Så egentlig, hva du vil å gjøre er eliminert Muda.
Og muda betyr ikke bare noe som er uproduktivt,
men alt som ikke er legge verdi i dag.
Fordi spesielt når du gjør noe
så usikker som gjør en oppstart, skape noe nyskapende,
Hvis du tror at du er kommer på denne måten, og du
begynne å bygge noe for dette, og deretter du
finne ut hva som egentlig skjer på og du går på denne måten,
så noe du gjorde over her er bortkastet, ikke sant?
Og så i Agile, har vi et uttrykk som heter
YAGNI, som er "Du Er ikke Gonna trenger det. "
>> [Humrer]
>> Så det er en veldig god ting å huske som du bygger nye teknologier.
Noe som du tror at du kommer til å trenge,
bare anta at du er ikke før du gjør.
>> Så det er interessant å se på eksempler på startups som har gjort det
og se hvor de kom fra.
Så PayPal faktisk startet som en måte å stråle betalinger mellom PDAer.
Men det viste seg at verden var ikke klar for mobile betalinger
i '99, ikke sant?
Vi er bare så vidt begynt å komme dit nå.
>> Flickr startet som et massivt multiplayer online rollespill spill.
Men det viste seg, som når folk skulle spille det,
at den mest morsomt aspekt ble deling av bilder.
Det er litt morsomt.
>> Og så Instagram startet som en gamified Foursquare.
Og de faktisk bygget ut hele app og så på det, og gikk wow,
det er altfor mye som skjer her.
Dette er altfor komplisert.
Og de bare kassert hele ting og sa, vet du hva?
Vi er bare nødt til å fokusere igjen på bildene.
Og det var det som var vellykket for dem.
Og så disse er de som gjort det, men når du på en måte se
over hele linja, den statistikken er ganske dyster.
Fordi statistikken er at ni av ti nye produkter mislykkes,
som er ganske abysmal.
Og som utviklere, som folk som jobber med teknologi,
Jeg tror at når vi ser på en stat som dette,
vi forstår hvor vanskelig det er å bygge tech når
du bygger noe som ikke er blitt bygget før.
Og vi antar at disse er sviktende fordi vi kan ikke bygge teknologien.
Men når du virkelig grave dypt, hva som happening-- disse produktene
er ikke sviktende fordi teknologien fungerte ikke.
De er sviktende grunn de som opprettet
dem var ikke i stand til å finne et marked for dem.
>> Min favoritt eksempel på Dette er et firma som heter
Actuality Systems, som var faktisk her i Boston.
De skapte en 3D holografisk skjerm.
Det er ganske badass, ikke sant?
De skaper det, og de fikk det til å fungere, og deretter
de tilbrakte de neste 10 years-- så de skapte dette.
Dette ville være imponerende å skape i dag, ikke sant?
De skapte dette over 10 år siden.
De tilbrakte de neste 10 årene prøver uten hell å finne et marked for det
og skape en levedyktig virksomhet ut av det, og til slutt måtte stenge,
og alt de kunne gjøre var å selge av en lisens for teknologien.
Så var de lykkes i nyskapende?
Jeg mener, de fikk teknologien til å fungere.
Det er utrolig.
Men hvis du prøver å faktisk bygge en levedyktig bedrift ut av dette,
ikke så mye.
>> Og så hva er interessant er det har vært forskning
i hva som er den største enkeltstående prediktor for oppstart svikt.
Har noen av dere ønsker å gjette hva dette er?
>> PUBLIKUM: Ingen markedet?
>> ABBY FICHTNER: Ingen marked, ja.
Så noe som faktisk burde jeg har said-- noe som startups gjøre,
at hvis de gjør dette, er det den største prediktor at de er
kommer til å mislykkes, eller den største indikator.
Så ingen markedet er liksom noe som skjer med dem.
>> Så Don [uhørbart] gjorde en undersøkelse inn i dette,
og hva han fant var den eneste største prediktor for oppstart svikt
stakk til den opprinnelige virksomhet plan-- som
er ganske forvirrende, ikke sant?
Fordi hvis du starter på alle nye venture,
du bør prøve å finne ut hvis du er på sporet eller ikke.
Selv den terminologien, på sporet, innebærer at du snakker i henhold til plan.
Og så hvis stikker til å planlegge betyr at du kommer til å mislykkes,
det er veldig forvirrende.
Høyre?
>> Og så det bringer oss til innovasjon mønster nummer
to, som er at du burde egentlig begynne i det små.
Og denne typen pauser vår mentale modell,
Jeg tror, ​​for hvordan folk tror om hvordan startups operere.
Fordi jeg føler at vi har fått dette bildet av startups som går stort eller gå hjem, baby.
Høyre?
Som jeg har fått en stor visjon, og bom.
Jeg kommer til å gå stor, og jeg er kommer til å bli den neste Facebook.
>> Men spørsmålet er hvordan gjør man det, ikke sant?
Hvordan går du fra ingenting, men en idé å like en milliard brukere,
som Facebook har?
Hvordan ville du selv bygge ut nok funksjoner fra dag én
at du kunne appellere til en milliard brukere?
Og selv om du ønsket å bygge neste Facebook
i morgen, hvordan kan du begynne å få folk på det?
Fordi ville noen av dere bruker "neste Facebook "hvis ingen visste du var på det?
Sannsynligvis ikke, ikke sant?
>> Og så hva jeg vise startups as-- når du er virkelig tidlig
stages-- liksom gjøre søket etter skjæringspunktet mellom vår store visjon
av hva vi ønsker å oppnå med det virkeligheten faktisk kan romme i dag.
Og den måten du gjør dette er vanligvis gjennom en serie
av små eksperimenter eller små oppgaver.
Så bare for å ta et par eksempler av selskaper som har gjort det stort
og hvordan de startet, Microsoft startet med å skrive
en versjon av BASIC, hvilke er et programmeringsspråk,
for Altair, som var som den første hjemme-PC.
Så jeg vet ikke nøyaktig hvor mange Altairs ble gjort,
men jeg gjetter bare noen få tusen.
Så dette er ikke et stort marked, ikke sant?
>> Og så, selvfølgelig, Facebook, som er den quintessential-- gå stor,
bli den neste Facebook-- startet her ved Harvard,
hvor det er bare 20.000 studenter.
Så igjen, ikke et stort marked.
Og så når du tenker på den mentale modell for hvordan startups
skal se ut, bør det ser mer ut som dette.
Du starter med den store visjon, men da må du gå små.
Og du finne ut en måte å dominere en virkelig nisje i markedet,
og deretter kan du bygge på at suksess å gå stor.
Og det er et par grunner til dette.
Det ene er om vi aksepterer det faktum at holde seg til den opprinnelige forretningsplanen sin
kommer til å mislykkes, skal vi finne 10.000 måter som ikke fungerer,
uansett, skal vi gjøre mye feil.
Vi kommer til å ha mye bom.
Hvis vi prøver å gå stor, skal vi bruke opp all vår tid og ressurser
på feil ting.
Og så det er mye bedre å gå liten så vi kan eksperimentere raskt.
>> Men enda viktigere, det er så mye enklere
å være vellykket når vi går liten, fordi alt du trenger å gjøre
er å finne det markedet som du vil gå after-- som virkelig nisje markedet.
Og så bare identifisere en ting som de er virkelig
døende å ha, og bygge det for dem.
Og så kan du være veldig overbevisende.
>> Slik som Altair brukere virkelig ønsket en måte å programmere datamaskinen sin.
Og jeg snakker ikke know-- jeg tror det var akkurat som vippebrytere
og blinkende lys, ikke sant?
Så jeg vet ikke hvordan de gjorde det.
Så gir BASIC slik at de kunne programmere den er fantastisk.
Eller Harvard studenter ville bare en enkelt, sentralisert student katalog,
ikke sant?
Og så Facebook bare måtte gi det en funksjon.
De trengte ikke å bygge det ut som det er i dag for å virkelig få trekkraft.
>> Så det tar oss til nummer tre, som er i orden
å finne at en funksjon som markedet er virkelig dø for,
du må virkelig dypt forstå dine kunder.
Og jeg føler at folk undervurderer viktigheten av dette--
spesielt i dag, når det er så mange startups som er der ute.
Hvis du virkelig er ute på hva som er skjer i oppstart plass,
du kommer til å finne 100 startups alle gjør det samme.
Høyre?
>> Og det er fordi alle kan se at teknologien er her i dag, ikke sant?
Men vi ønsker å være her.
Slik at folk ser disse hullene, og alle prøver å gå etter disse hullene.
Og du har alle disse startups alle gjør det samme,
og du liker, hvorfor er ikke noen av dem lykkes?
Det er et gap her.
Jeg tror at de som som kommer til å lykkes
er de som tar seg tid til virkelig forstår sine kunder.
Et godt eksempel på dette, Jeg tror, ​​er Dropbox.
Når Drew Houston, grunnleggeren, gikk for å prøve å skaffe penger til Dropbox,
VCS virkelig motet ham.
De er like, jeg forstår ikke hvorfor du selv inn i dette rommet.
Det finnes allerede som en million milliarder sky lagring startups der ute.
>> Og Drew var som, ja, men bruker du noen av dem?
Og de var ikke.
Og så føler jeg meg som Drew lyktes fordi A,
Han startet med et lite marked.
Han prøvde ikke å gå etter alle.
Han gikk etter hardcore Teknologikyndige som har
en rekke enheter, en masse av datamaskiner, og de
har dette problemet i å overføre filer.
Og han bare rettet dem.
Og alt han hadde å gjøre var å gi en løsning som fungerte for dem.
>> Så igjen, jeg føler at det er mange myter rundt startups,
fordi vi ser så mange startups skjer i dag.
Og du bare høre 20 000 fot visning av oh, de gjorde det over natten.
De var en suksess.
Men myten om hvis du bygger det, de vil come-- når du virkelig
grave dypt inn i hva som skjer i disse suksesshistorier, tid
og igjen, jeg tror det du finner er grunnleggere
som gikk til disse ekstraordinære lengder for å forstå sine kunder.
Så bare for å gi et par examples-- jeg vet ikke om dette fortsatt er tilfelle,
men i det minste innledningsvis, ett av grunnleggerne av Airbnb
ikke eier eller leier en bolig.
Han bare gikk rundt og levde i Airbnbs.
Som jeg ikke engang vet hva som så ut like-- som å leve ut av en koffert?
>> Eller Ben Silverman fra Pinterest er fantastisk på dette.
Han gikk og personlig nådd ut til de første 5000 kunder.
Han ga dem sin mobiltelefon.
Han møtte dem til frokost.
Jeg bare snakket til sine CTO et par uker siden.
Og de går inn inn i nye land nå,
og han kommer ut og gjør det igjen.
Så han er utrolig for å gå ut og individuelt snakke med folk.
Så, selvfølgelig, som du kommer ut og å ha disse samtalene, hva
du ønsker å gjøre er alltid lære av dine kunder
om hva som kommer til å være fornuftig og hva som kommer til å være vellykket.
Jeg føler meg som den beste startups, de beste innovatørene,
behandle innovasjon som om det var en vitenskap experiment-- eller i en svært
vitenskapelig måte, jeg tror jeg skal si.
>> Så jeg er ikke en vitenskapsmann, men som Jeg forstår, forskere kommet opp
med hypoteser, og deretter de utvikler eksperimenter for å validere eller avkrefte
sine hypoteser.
Og så spørsmålet er hvordan kan vi gjøre det med innovasjon?
Vi har en idé, men det er bare en idé.
Hvis vi virkelig gjøre noe som aldri har blitt gjort før,
alt vi har er gjetninger.
Høyre?
Og så hva er noen eksperimenter som vi kan gjøre for å validere eller avkrefte
disse ideene uten å bygge ut hele greia?
>> Så snakker er stor, og jeg kan faktisk ikke
understreke hvor strongly-- hvor viktig det
er å gå ut og snakke med din kunder, i det minste innledningsvis,
å forstå hvem de er, hvilke problemer de
har i dag, hvordan de er løse dem i dag.
Men snakker kan bare ta deg så langt.
Høyre?
Du kan ikke bruke snakke å si, hei, jeg har fått denne flott idé!
Ønsker du å kjøpe det?
Fordi de kommer til å være som, oh, ja selvfølgelig.
Det høres flott ut.
>> Fordi folk ønsker å oppmuntre deg.
De ser at du er begeistret noe, så de kommer til å si ja.
Og people-- mennesker er bare fæl til å forutsi deres atferd.
Og så hvis du spør them-- hvis du sier, Jeg kommer til å, på et tidspunkt i en fremtid,
slipper denne abstrakt, hypotetiske produkt, er du kommer til å ønske det?
De kan si nei, men hvis du faktisk sette den foran dem,
de kanskje ønsker det.
>> Og så egentlig, for å gjøre det test av forståelse
hvis folk kommer til å vil det eller ikke, du virkelig
trenger å sette noe foran dem.
Så jeg liker dette sitatet fra Linus Torvalds, som er "Talk er billig.
Vis meg koden. "
Eller hvis du er en oppstart, du kanskje si, "Talk er billig.
Vis meg MVP. "
>> Så har dere hørt MVP, Minimum levedyktig produkt?
Det er en slags denne buzzword som Jeg elsker og hater samtidig.
Fordi jeg elsker konseptet med det, men det blir litt for mye.
Men ideen er gyldig, som er ikke gå å bygge ut
dette produktet som kommer å ta deg et år å bygge.
I stedet, finne ut hva som er det ene ting som folk dør for?
Hva er den minste ting Jeg kan bygge for dem?
Og sette det foran dem, og se hvordan de reagerer.
>> Så kvintessensen MVP er en destinasjonsside.
Jeg er sikker på at dere har sett dette.
Hvis du prøvde å melde seg på Ello eller Gmails nye innboksen, og de er like oh,
vi er ikke klar ennå!
Jeg antar de er litt forskjellige, fordi de er klare.
Men de gir deg en destinasjonsside, og det er, det er kun for inviterte akkurat nå.
Men gi oss din e-postadresse.
Rett
Mange steder vil gjøre dette før de har selv bygget ut produktet,
bare for å se om det er interesse eller ikke.
Så med Dropbox, trakk Houston, der var kompleks teknologi bak det.
Så gikk han, og han har funnet ut technology-- slags bevist at ut,
at det skulle fungere.
Men før han bygget ut det endelige produktet,
han gjorde dette mock-up på sin datamaskin, Dette tre-minutters screen
video-- svært rufsete.
Sette den ut på Hacker News, fordi han visste var liksom hans publikum,
var de virkelig tekniske folk.
Sette opp en destinasjonsside som bare sagt, her er videoen.
Vi har ikke lansert ennå, men hvis du er interessert, gi oss din e-postadresse.
>> Over natten, fikk 75.000 sign-ups, noe som er utrolig.
Selv i dag, ville det være imponerende, men i dag, de
har som 300 millioner brukere, ikke sant?
Når han postet dette, ingen visste hvem Dropbox
var fordi de ikke eksisterer ennå.
Og så det var en veldig sterk signal at han hadde fått noe riktig.
>> For å gi deg litt mer omfattende et eksempel på dette,
Har dere vet Buffer?
Det er en sosial media deling av området, og ideen
er-- jeg pleier å lese nyheter på som 02:00, fordi jeg
ønsker ikke å gå i dvale.
Og så jeg kan lese som 10 artikler som alle er veldig kult
og jeg vil dele dem med folk.
Men A, hvis jeg dele dem ut på Twitter akkurat nå,
ingen er våken om 02:00 bortsett fra for meg.
Og B, hvis de er våkne, de er som hvorfor er du
spamming meg med 10 artikler på en gang, ikke sant?
Og så hva den gjør er det form av en kø eller en buffer
at du legge ting til, og det vil presse dem ut et par ganger om dagen
på en mer realistisk tidsplan.
>> Så dette er hvordan det ser ut i dag.
Det er ikke hvordan det begynte.
Grunnleggeren hadde denne ideen, og han trodde dette var en god idé,
men han ønsket ikke å bygge den.
Han ønsket ikke å slutte sin jobb ennå før han
fikk noen bekreftelse på at andre mennesker trodde det var en god idé, også.
Slik at han ikke engang trenger en video.
Det var slik en enkelt konsept.
>> Bare begynn med Twitter, setter opp en destinasjonsside.
Dette er hva vi gjør.
Han tweets det ut.
Når folk klikker Planer og Prising, det bare gir dem
en "du fanget oss før vi er klar. ", men hvis du er interessert,
gi oss din e-postadresse.
Tweets det ut.
Folk dro til området.
De fikk sin e-postadresse.
>> Han var som, OK, det er en ganske god indikator på at det er en viss interesse,
så jeg er klar til å gå videre til neste trinn.
Men jeg ønsker ikke å bygge det ennå.
Jeg ønsker å see-- folk er interessert, men kan jeg tjene penger på det?
Kan jeg gjøre det i en bedrift?
Så alt han gjorde var lagt til en midtside når folk klikket Planer og Priser
med tre priser arbeid planer ett var gratis.
To ble betalt.
>> Holdt tweeting det ut.
Folk holdt klikke.
De fleste gjorde gratis plan, men noen folk gjorde det betalt plan.
Han liker, vet du hva?
Det er nok validation-- ikke for meg kanskje til å slutte i jobben min
og tilbringe et år på dette, men for meg å bare gå heads-ned og gjøre
en veldig enkel versjon av denne.
Han trodde det skulle å ta ham en dag.
Teknologi er hardt, så det tok ham som syv dager.
Men det var nok for ham å tilbringe syv dager på den.
>> Og veldig raskt, begynte han få brukere på den første versjonen,
selv om det var veldig minimal.
Og hva var fantastisk om det var var han
i stand til å se hvordan folk ble virkelig bruke det,
og deretter slags utvikle seg det basert på dem som bruker den.
Så Buffer er fantastisk, fordi det er et veldig enkelt eksempel.
Ikke all teknologi er Så enkelt er det, men dette
er liksom kvintessensen Lean oppstart tilnærming, ikke sant?
Dette er great-- du er teste det hvert trinn,
og du bare kommer langt nok til at du har
validert at det er slag av verdt din tid til å gjøre.
>> En annen fin måte å få validering naturligvis
gjør en crowdfunding kampanje som kickstarter,
hvor du kan få forhåndsbestillinger.
Dette gjør mye fornuftig hvis du er gjør noe som er maskinvare.
Igjen var Pebble den største Kickstarter
inntil den tittelen fikk tatt av en cooler-- gjorde dere ser dette?
Som en faktisk kjøler som du bringe til piknik slå ut,
så de fikk mer enn $ 10 millioner.
[Ler LITT]
>> Men igjen, som Dropbox, med Pebble, var det komplisert teknologi.
De måtte gjøre en proof of concept, sørg for at de kunne bevise ut
at teknologien kan fungere.
Men så er det dyrt å produsere, så før de faktisk produsert,
de satt opp en kickstarter.
Og de brukte det til få forhåndsbestillinger, ikke sant?
De sa at hvis vi kan få $ 100.000 i forhåndsbestillinger,
det er verdt det å gå fremover.
De fikk $ 10 millioner, så gjør ganske bra-- ganske god validering.
>> Så disse ideene er alle virkelig stor, men som vi sier i startups,
ideer er en krone et dusin.
Det handler om henrettelse.
Så dette er min favoritt del er "Focus!
Og få dritt gjort. "
Så de beste gründere er i stand til å bare ha
denne sprø, intens hyper-fokus og få ting gjort på et utrolig tempo.
>> Så jeg slags gå gjennom noen av utviklingspraksis.
Og stille spørsmål hvis du har dem.
Jeg var ikke helt sikker på hvor mye dere visste om utvikling praksis,
så snilt av en diskusjon om hva som
ser ut når du er utvikle noe som dette.
Så det første er å finne ut OK, hva
er det at jeg bør fokusere on-- som kan bli virkelig utfordrende når
du gjør noe nytt.
Fordi alle har alt disse ideene, og det er
så mange forskjellige retninger du kan gå, og så mange forskjellige spørsmål
som du har.
>> Så steg nummer en, figur ut hva du skal fokusere på.
Mange ganger, som utviklere, som folk som tenker på teknologi,
vi egentlig tenker om produktene.
Vi tenker om ting slags i dette order-- først, kan jeg bygge det?
Forutsatt at jeg kan bygge den, deretter kan jeg få folk til å vite om det?
Forutsatt at jeg kan, kan Jeg tjene penger på det?
>> Men hvis vi prøver å gjøre en levedyktig bedrift,
vi kanskje vil være å tenke av de i motsatt rekkefølge.
Grunnen er at jeg føler like-- og Jeg gjør dette selv, så jeg får det.
Jeg føler at vi får veldig hung opp på denne "Kan jeg bygge det?"
spørsmålet, fordi hvis du er en teknologi person-- hvis du er en developer--
du egentlig tenker om det.
>> Men sannheten er som regel, når vi komme opp med en idé til en oppstart,
vi kommer opp med det basert på Jeg har sett denne teknologien her
og denne teknologien her og denne teknologien her,
og hvis jeg bare kombinere dem på noen ny måte,
Jeg tror det ville være veldig interessant.
Vel, hvis jeg har allerede sett den teknologien på de steder,
du slags vet det finnes, ikke sant?
>> Så sikker, gjøre noen bevis på konsepter.
Hvis det er noe teknisk risiko i det.
Men for det meste, de tingene at vi kommer opp with--
med mindre vi er virkelig fantastisk og gjør noe helt nytt, i hvilket tilfelle
finne ut om du kan bygge den.
Men vanligvis mesteparten av startups jeg skjønner, du kan bygge den.
Det er ikke engang et spørsmål.
>> Så begynne å tenke på er noe som folk
kommer til å være i stand til å betale meg for Og deretter hvordan jeg kommer til å nå dem?
Det er virkelig vanskelig, spesielt hvis du er en teknisk person,
har du en måte å nå ut til disse menneskene
og få dem til å kjøpe produktet?
>> Så når du finne ut, OK, hva er det question-- slags alltid har i tankene,
Dette er det viktigste spørsmålet at jeg må kjøre mot,
eller det viktigste at jeg må validere.
Og så du ønsker å komme tilbake til denne oppfatningen av å eliminere avfall.
Bare finne ut som magreste og mest effektive måten
at du kan gå om svare på det spørsmålet.
>> Så jeg snakket om minimum levedyktig produkt.
Jeg vil si komme inn i denne tankegangen av minimum levedyktig everything--
etter som jeg mener ikke at du bør være å gjøre en crappy jobb på ting.
Jeg mener, hvordan kan du kutter ut avfallet?
Hvordan får du helt rett til hjertet av saken
og finne ut hvordan å validere ting uten gull-plating,
uten å gjøre mer enn du må.
>> Så bare for å gi noen eksempler, Jeg føler at i utgangspunktet, du er
prøver å finne ut jeg har denne flotte ideen.
Er noen selv kommer til å ønske det?
Så en veldig enkel måte å gjøre det på er en landing side, som vi snakket om.
Du trenger ikke å skrive noen kode for det.
Det finnes verktøy som gjør det for deg.
>> Hvis du sier, OK, jeg skjønte det ut.
Nå vil jeg jeg antar at-- OK, folk synes å ønske det.
Ville de faktisk betaler meg penger for det?
Du kan gjøre ting som hva Buffer gjorde med prisingen side,
eller enda bedre, en Kickstarter og få forhåndsbestillinger.
Bestillinger
>> Den neste tingen som jeg tror du er kommer til å være som ønsker å se på er-- OK,
det virker som folk ville ha det.
Det virker som folk vil betale for det, men spesielt med apps,
vil folk faktisk bruker det?
Så jeg vet ikke statistikken, men de er ganske elendig.
Et stort antall av apps få lastet ned og deretter aldri brukt.
Og det er ikke nyttig.
Det er fint at du fikk en Mange laster det ned.
Men hvis det ikke er brukt, er du ikke kommer til å feste rundt for lang.
Når du tenker om at første versjon
at du ønsker å sette ut det-- minimumslevedyktig product--
tenke på hva er det egentlig at jeg prøver å teste?
Og hva kan jeg gjøre det bare tall det ut?
Jeg bare slags tok en gjetning på dette.
Jeg vet faktisk ikke hva Buffer s første versjonen så ut nøyaktig.
Men hvis du tenker på Buffer-- bare på grunn av denne enkle example--
du kanskje tror dette er hva de føler
som sitt første minimum levedyktig produkt.
Jeg må være i stand til opprette en brukerkonto,
selvsagt, koble den til min sosiale medier kontoer.
Jeg må legge til innlegg som tweets inn i min buffer.
Redigere dem.
Slette dem.
>> Stille inn tiden når jeg ønsker de å bli lagt ut.
Tydeligvis, programvarebehov å automatisk legge til Twitter
eller hva basert på at tidsplanen.
Og så skal jeg være i stand til vise en historie med mitt innlegg.
Det føles ganske minimal, ganske grunnleggende, ikke sant?
>> Jeg oppfordrer alltid startups-- liker spesielt, dette er lett for oss,
fordi det ikke er vår baby.
Høyre?
Være som, oh, yeah uansett se på det igjen, og fortsetter å si er det en måte
at jeg kan få det strippet ned enda mer?
>> Så hva er det vi er prøver å finne ut?
Hvis vi prøver å figur ut om de vil bruke det,
vi prøver å se om de er enda kommer til å legge inn noe til støtfangeren?
Så dette føles litt Hacky, men hvis de har ikke lagt den til Buffer
enda, gjør du ikke egentlig må tillate dem å redigere
eller slette eller vise innlegg i historien.
Hvis du kan plante det noe det ut veldig raskt
og se om folk kan selv legge til posteringer til det, når du ser det,
kan du raskt starte tilsette på denne funksjonaliteten.
Men bare få noe der ute.
Du trenger for å tillate brukeren trenger å sette et innlegg tidsplan?
Sannsynligvis ikke, hvis de er som meg og de er akkurat som,
Jeg vil ikke at mine alle mine godbiter kommer ut på 02:00 på søndag kveld.
>> Du kan si at disse er de mest populære ganger.
Uansett, vi bare går å legge det i henhold til det.
Du kan sikkert gjøre det.
Og da jeg slags gjort dette opp, fordi Jeg vet at de bare startet med Twitter.
Men selvsagt, kan du bare plukke den sosiale medier
nettverk som er mest sanse og bare begynne med det.
Og så nå du er nede til fire av 10.
>> Og hvis du kan få noe der ute, et kjæledyr peeve min
er at folk tror og MVP betyr crappy produkt.
Og jeg tror ikke det er behov for.
Jeg tror du kan få noe der ute at det er fortsatt er brukbart,
men er ikke gull plated-- er bare den absolutte bjørnen minimum.
Og jeg antar du har til slags figur ut basert på publikum hva som skjer
å gi mening eller hva er ikke.
>> Men mange ganger du får noe der ute mer minimal
enn du ville think-- bare en test, hvordan folk bruker den.
Så som du bygger ut disse funksjonene,
du ønsker å tenke på hva som er minimumslevedyktig prosess.
Og så mange ganger når vi tror om virkelig lettvektsprosesser,
vi tenker på smidige prosesser.
Vi tenker på lean-- dette er litt bit random-- bare noen smidig og lean
bøker som jeg liker.
Så det er gode rutiner som fra Extreme Programming
og kontinuerlig integrasjon, og refactoring,
som jeg skal snakke med en liten bit.
Men tingen er, når du begynner å få inn i Agile og gjennomsnitts praksis,
det kan veldig fort bli overveldende.
Og det kan ende opp med å begynne real overkill for en oppstart.
>> Så ting er at mange av disse bøkene
snakker om hvordan å gjøre Agile når du er
å gjøre et produkt for en etablert selskap.
Høyre?
Og du vet hvem markedet er, og du vet hva produktet veikart.
Og de ender opp-- selv om vi skal
å være lys weight-- de ender opp faktisk å være altfor tungvekter
for vår oppstart, fordi oppstart er bare
opererer på dette helt annet nivå.
Så min følelse er at når du kommer en oppstart,
du må være scrappy som faen.
Høyre?
Så i utgangspunktet, det er ingen prosess.
Du ønsker å holde det så enkelt som mulig.
Og bare legge prosess som er liksom en just-in-time prosess.
OK, ser vi at det er et problem?
La oss legge akkurat nok prosess for å løse det problemet.
Vet du hva jeg mener?
Det er fordi du ikke vil ha noen av oss som holder deg nede, ikke sant?
>> Scrum er en virkelig populær prosess for Agile utvikling.
Jeg vet ikke om dere er kjent med dette.
OK, samt--
>> [Humrer]
>> Det ville være litt for kill for en oppstart.
Så jeg vil ikke bekymre deg for det.
Så OK, hva er det hvis du tenker på absolutt enkleste ting som jeg trenger.
Vel, jeg må sannsynligvis holde oversikt over hva
Jeg gjør, spesielt hvis det er mer enn én person,
men selv om det er én person.
Hva er det jeg jobber med?
>> Så en enkel oppgave board-- veldig enkelt.
Dette er hva jeg ønsker å gjøre.
Dette er hva jeg jobber med.
Dette er hva jeg har gjort.
Det eneste problemet som jeg ser når jeg ser startups gjør noe sånt som dette,
er at svært raskt, deres in-progress kolonne
en tendens til å se ut som, som ikke er veldig helpful-- spesielt hvis det er
bare én person eller bare en utbygger.
Høyre?
>> Fordi du ikke å få noe gjort.
Alt du gjør er å gå frem og tilbake prøver å få alle disse ting gjort.
Og så dette er et veldig godt eksempel av hvor akkurat nok prosessen kan komme.
Så Kanban er en virkelig flott verktøy.
Det kommer også fra Lean produksjon.
>> Og ideen er at det vi ønsker å gjøre er å sette begrensninger
rundt hvor mye arbeid vi kan håndtak til enhver tid.
Og så hvis vi er én person, da vi kan bare utføres på ett element om gangen.
Unnskyld.
Så alt det andre ting behov for å gå over der.
Så det vi gjør er at vi legger arbeid i fremgang begrensninger på søylene.
Hvis det er to personer, kan det være to.
Du kan finne ut hva er mest fornuftig for deg.
>> Men ideen er å holde ting tilregnelig, slik at du er bare
gjøre én ting om gangen.
Du er i stand til å gjøre det.
Du er i stand til å faktisk få det gjort.
En ting å huske på er-- hvis du har en ett element
som du gjør, men element tar tre måneder, at
ville være vanskelig for en oppstart, selvsagt.
Du må være i stand å være fleksibel og være
i stand til å håndtere ting som de kommer på deg.
Du kan ikke si at jeg ikke gjør noe i tre måneder
før jeg får innloggingsbildet gjort.
Jeg vet ikke.
>> Så jeg anbefaler startups til holde dette veldig kort,
å holde disse oppgavene så at de passer inn i en dag.
Selvfølgelig, hvis det er mer komplisert, at må kanskje være litt lenger.
Men finne ut hva som fungerer best for deg.
Du kan prøve forskjellige lengder.
Men generelt, akkurat som en eksempel, hvis du holder alle oppgavene
slik at de passer i en dag, at betyr at hver eneste dag,
du får noe gjort.
Og du gir verdi.
Og at momentum kan virkelig beveger deg fremover
i stedet for situasjonen før, hvor du har 500 ting går,
og ingen av dem er ferdig.
Den andre tingen, skjønt, er fortsatt på jakt
på denne to-do column-- jeg er overveldet å se på det.
Og så hvis jeg var en utvikler og jeg var jobber med A, og jeg var som oh, dritt.
Jeg har B og C og De og E og F og G og H. Blah!
Kommer nedover veien.
Jeg er som galne, og jeg "m prøver å finne ut hvordan design skal
for å få plass til alle disse tingene.
Og sannheten er at hvis vi aksepterer faktum at vi ikke egentlig helt vet
hva produktet kommer til å trenge å se ut før vi har satt foran
av en kunde, så vet vi egentlig at vi trenger alle disse oppgavene ennå?
Eller er vi på en måte lure oss selv?
>> Så hvis du virkelig har alle disse ideene, stor.
Sett dem i en notatbok eller en regneark eller noe sånt.
Men jeg anbefaler startups til holde en work-in-progress limit
på to-do-kolonnen, også.
Det er et absolutt maksimum, Jeg vil si, hvor mye
du kan få gjort i en eller to uker.
Slik at den ikke engang å være så mange.
>> På den måten er du bare hyper-fokus på dette
er hva jeg gjør, å få gjort denne uken.
Eller kanskje disse to ukene, ikke sant?
Og ingenting annet er å få i din vei, og du er bare
å sørge for at du er få det ut der.
Og spesielt når du begynner å legge nye teammedlemmer, virkelig hjelper dette.
Mange mennesker liker å gjøre dette i programvare, som du kan.
Men det er enda bedre hvis du alle kan være på samme plass
og bare sette den opp på en vegg.
Det er bare veldig synlig, og alle kan bare
se det, og se hva som er viktigst.
>> Så OK, det er hvordan du er finne ut hva de skal gjøre.
Som du gjør det, du ønsker å tenke
om hva som er minimumslevedyktig design?
Eller i Agile, vi faktisk har noe som kalles
emergent utforming, som er den samme idé.
Så har dere hørt om emergent utformingen før?
OK.
>> S- faktisk, jeg prøver å huske where-- OK.
Slik at ideen om en kjøpmann Designet er heller enn å komme opp
med denne store, upfront design og si jeg er
kommer til å tilbringe en måned på å finne ut riktig arkitektur hvilke komponenter
gå der og alt, la meg bare designe nok for funksjonene
som jeg vet jeg setter i denne første utgaven.
Og ingenting else-- eller funksjonene at jeg gjør denne uken, selv.
>> Og da bare som jeg trenger nye funksjoner gjør jeg finne ut av design for de.
Du er ikke å finne ut utformingen forhånd.
Jeg tror i virkeligheten, er det ikke dette på-bryter eller dette veksle.
Jeg tror det er mer av en spekteret av hvor du har fall
på sikkerhet til usikkerhet.
Og så hvis du er i en oppstarts opp, eller hvis du bygge noe som er aldri
blitt bygget før, du er pen langt over på usikkerhet kurve
her, ikke sant?
>> Og hvis du tenker på det i vilkårene i virksomheten plan-- lignende,
vi snakket om enkelt største prediktor for svikt
er å holde seg til den opprinnelige forretningsplan.
Hvis du gjør dette stor upfront forretningsplan,
og du sier jeg skal bare blindt følge det og ikke gjøre noe.
Men du bare kommer til å mislykkes, ikke sant?
Fordi det var for mye usikkerhet.
Og jeg føler meg som den samme gjelder for utformingen.
>> Sorry, så i stedet for å gjøre en stor upfront forretningsplan,
du ville gjøre en meget lys vekt forretningsmodell
lerret, som du kanskje har hørt om.
Det er som en ett-personsøker, bare å få mine ideer ut.
Det er ikke det at du ikke gjør det tenker på det i det hele tatt.
Det er godt å tenke på det først.
Men bare få det noe virkelig fleksibel ut det-- bare én side.
Og så, som du går, type dukke opp den planen over tid
som du får fra kunder, og du kan tilpasse seg dem.
>> Og så deretter det samme ting er sant for design.
Du kan gjøre en stor, upfront design, men at
gir ikke mening hvis det er mye usikkerhet.
Mange vil hevde det er aldri så mye sikkerhet i programvare,
selv om du ikke gjør i oppstart.
Så du aldri ønsker å gjøre det stor av en upfront design.
Men jeg føler at den nivå av design kommer
å variere basert på hvor mye sikkerhet eller usikkerhet er det.
Og så hvis du har ingen freaking anelse og du er bare å kaste noe ut
det liker en landing side, selvsagt, du er
ikke kommer til å gå ta deg tid til arkitekten et helt system.
Det er latterlig, ikke sant?
Slik at du ikke trenger noen upfront design.
Mange ganger, den første versjonen du satt ut av programvare for en oppstart
bare blir kastet bort.
Og så mange ganger, selv selv om jeg kanskje si dette,
du kan bare slags hacke noe sammen.
Det er trolig kommer til å bli kastet bort.
Men igjen, bruke det just-in-time Ideen til utformingen også.
At OK, vet du hva?
Dette er faktisk noen trekkraft.
Noen mennesker er interessert i dette.
Jeg kommer til å legge noen funksjoner på.
Nå føler jeg at jeg bør være en litt smartere om design.
>> Så ideen er som designe, bare holde dette YAGNI i tankene.
Du er ikke Gonna trenger det.
Ikke designe for ting som ikke er der ennå.
Og holde det enkelt, dum principle--
gjøre de enkleste ting som kunne fungere.
>> Mange ganger, er det interessant, fordi som utviklere,
vi får lært å gjøre disse virkelig komplekse konstruksjoner.
Og vi lærte at det er bra.
Men det hindrer oss fra å være fleksibel, og det kan være veldig sløsing
hvis vi ender opp med å gå i på ulike retninger.
Så Agile slags sier, ikke gjør det.
Bare finne ut hva enkleste måte, den enkleste kode
at du kan sette inn her som kommer til å gjøre det arbeidet.
Og så hvis jeg trenger å legge på det, kan jeg slags fikse den koden opp
og omadressere design.
>> Så det er noe som heter refactoring det er veldig viktig når
du gjør emergent design.
Og ideen med ommøblerer er-- beklager, jeg kommer til å sikkerhetskopiere litt.
Så hvis du gjør emergent design, du bare designe for fremtiden
at du har i dag.
Men det betyr ikke at at du er hacking.
Det betyr ikke at når du legge til en annen funksjon,
du bare kommer til slags duct tape den på.
Høyre?
Fordi det kommer til å gi du denne stor ball av mud-kode
som kommer til å være umulig å vedlikeholde.
Ideen med refactoring er OK, jeg vet jeg bare trenger, si, Twitter i dag,
så jeg kommer ikke til å gjøre dette stor abstraksjon som sier,
oh, la meg få denne Abstraction Layer som vil fungere med alle sosiale medier
nettverk som jeg noensinne kunne muligens tenker på det i fremtiden,
fordi det tar tid.
La meg just-- den enkleste ting som kunne virke
er la meg bare gjøre det kjent med Twitter,
fordi det er alt jeg trenger å gjøre i dag.
Så i morgen, vi innser OK, vi gjør trenger for å gjøre dette arbeidet med Facebook.
Så refactoring ville si, la meg revidere utformingen før jeg selv legge til Facebook,
og si gitt at jeg vet at nå trenger jeg
å håndtere de fleste flere sosiale nettverk, hva ville optimal design ser
ut?
La meg refactor koden å håndtere at design,
og da kan jeg koble Facebook-funksjonalitet i.
Betyr det fornuftig?
>> Så mange mennesker tror, ​​når de høre noe sånt som emergent design,
at du gjør mindre utforming eller at du bare hacking.
Men sannheten er at du er faktisk gjør mer design.
Det er liksom det samme ting med planlegging, ikke sant?
Du faktisk gjør mer planning-- det er
bare at i stedet for gjør det hele opp foran,
du gjør det kontinuerlig hvert.
>> Så jeg tror det er virkelig flott at dere tar CS50,
fordi jeg hører dette så mange ganger en dag, kan jeg ikke engang fortelle deg.
Folk kommer bort til meg og de sier: Abby, jeg har dette god idé!
Alt jeg trenger er en utvikler.
Og jeg slags ønsker å skyte meg selv i hodet når jeg hører det.
>> Fordi den slags assumes-- de vil komme opp,
og de vil være som jeg har ideen alt funnet ut.
Jeg har fått forretningsplanen.
Jeg har fått design.
Jeg trenger bare en utvikler til gå kode det for meg, ikke sant?
Og det er bare forutsatt at de har fikk alle svarene foran,
og denne personen kan bare gå kode det for dem,
og de kommer til å gjøre en million dollars-- som
bare ikke tar Faktisk alle usikkerheter.
>> Så hvis vi slags se på trinnene av development-- og jeg beklager.
Dette er en liten foss-y.
Men hva vanligvis skjer er at du figuren ut OK, dette er hva jeg ønsker å kode.
Du ta litt tid å utvikle den, teste den.
Kvalitetssikring er å teste den.
Og så når du har fått en hel utgivelse sammen,
som kan ta en måned.
Det gjør to-tre måneder.
Så du slipper det ut, ikke sant?
>> Men hvis vi sier, OK, la oss tenke på hvordan vi gjør
maksimere den læringen som skjer her?
Fordi hvis vi bare gå heads-ned for tre måneder eller et år eller noe
og sette noen kode ut det og det ikke fungerer,
så vi er litt skrudd, ikke sant?
Så hvor kommer læring skje her?
Noen læring skjer når vi gjør krav,
fordi vi snakker med kunder, og vi prøver å forstå om dem.
Men realiteten er at mest læring ikke
skje før vi faktisk putte noe i sine hender
og se hvordan de bruker det.
Og så hva dette betyr er at den tiden, de stedene
at vi bruker mest tid-- som er utvikling og QA eller testing-- det er
svært lite læring som skjer.
>> Og så hvis vi ser på dette, og si hvordan kan vi maksimere læring?
Eller hvordan kan vi redusere tiden som skjer mellom læring?
En flott ting er kontinuerlig distribusjon.
Jeg vet ikke om dere har hørt om kontinuerlig distribusjon.
Så ideen med at-- stedet å si: OK, vi kommer til å gå.
Vi har denne utgivelser på tre måneder.
Vi kommer til å bygge alle funksjonene for det.
Og da bare i ende av frigivelse er
vi skal faktisk skyve den i produksjon
og sette den foran brukere.
>> Ideen med kontinuerlig distribusjon seg at i den andre ytterligheten.
Så er dere kjente med versjonskontroll?
Så ideelt sett, når du jobber på din kode, hver gang du
legge til noen ny funksjonalitet, du er skal sjekke den inn versjonskontroll.
Så hvis du skru noe opp, kan du alltid gå tilbake.
Eller du kan se hva som er endret, hvis noe er brukket.
>> Så ideen med kontinuerlig distribusjon er
så snart du sjekke noe inn i versjonskontroll,
det presser koden til en iscenesettelse server.
Det kommer til å kjøre automatiserte tester på det, må du ikke ødelegge noe.
Hvis du ikke ødelegge noe, det kommer til å presse det rett ut
fra produksjonen.
>> Så boom.
Det er i hendene på kunden.
Svært forskjellige.
Men hvis vi gjør dette, hvis vi presser ting ut til kunden så fort
som mulig, så vi får koden i deres hender.
Vi kan se hvordan de er jobbe med dem,
og vi kan virkelig maksimere læring.
>> Så jeg kommer til å snakke gjennom dette litt mer,
fordi jeg vet ikke om det var-- kontinuerlig distribusjon
kan være ganske ekstrem, ikke sant?
Og det kan være ganske tøft å gjøre.
Så folk, selskaper vanligvis slags starte med kontinuerlig integrasjon,
og de jobber seg fremover.
>> Så kontinuerlig integrasjon er dette konsept som er slags første del
at jeg snakket om.
Så ideen med kontinuerlig integrasjon er
du har fortsatt utgivelsesplan.
Du kommer til å slippe hver uke eller hver tredje måned eller hva er.
>> Men hver eneste gang noen sjekker noen kode i,
det gjør skyve koden på en iscenesettelse server.
De iscenesettelse server utseende som produksjon og det
driver en rekke automatiserte tester på dem for å sikre at ingenting blakk.
Hvis noe brøt, så er det kommer til å fortelle alle at hei,
oppbyggingen ble brutt.
Og alle har stoppe og sørge for at det er fikset.
>> Så på den måten, du er alltid garanterer at alt som du sjekker inn
er å holde koden på en OK tilstand.
Så når du er klar til å slippe den i brøkdel, du skjønner alt.
Kontinuerlig levering er liksom den Neste trinn i denne prosessen, som
er at hver gang du check-- det står samme thing-- hver gang vi sjekker
noe inn i versjonskontroll, det skyver det til iscenesettelsen server.
Det kjører testene på den.
>> Men kulturen er satt som slik at du alltid
holde koden, slik at det kan bli presset til produksjon til enhver tid.
Så med kontinuerlig integrasjon, du kan ha et veikart og si,
Vi kommer bare til å skyve den til produksjon i tre måneder.
Høyre?
Det gjør egentlig ikke å være klar for å bli sett av en kunde.
Men med dette, du sier på et gitt tidspunkt,
du kan være som Jepp, jeg er fornøyd med denne funksjonssett,
selv om vi er bare to uker i.
Jeg kommer til å gå videre og skyve den ut til kunden,
og jeg vet det kommer til å være OK.
>> Og så må du kanskje noe som brytere i koden din
som sier for funksjoner som er bare halvgjort.
De er faktisk ikke synlig.
Hvorfor er det synlig for kunden ennå?
Eller noe sånt.
Men du alltid sørge for at du ikke har noe
det er i denne rare tilstand, fordi det kan skyve ut til produksjon til enhver tid.
>> Og akkurat når du er i, har du snill av fått alle vant til at ideen
at du alltid koding slik at den er klar til å gå ut i produksjon.
Da er det ikke så vanskelig å flytte til kontinuerlig distribusjon, som
er at hver eneste gang du sjekke noe i,
så lenge testen passert, den går ut til produksjon.
Gjør den slags fornuftig?
>> Så det kan fortsatt være veldig skummelt konsept, er men det
interessant å se på hvordan noen selskaper gjør det.
Så Etsy gjør en virkelig god jobb med dette.
Hvis du er interessert, de har fått en blogg som
snakker om hvordan de gjør kontinuerlige distribusjon, noe som er virkelig fantastisk.
De distribuere til produksjon opp 50 ganger en day-- riktige?
Som er crazy-- kan du tenke deg om Du går til Etsy nettsiden, 50 ganger
i dag, er at området blir oppdatert bak kulissene.
>> Og i 2011, de utplassert 10.000 ganger i løpet av året med 100 ingeniører.
Og hva de sa er i strid med hva du kan think-- som herregud,
det er forferdelig!
Koden, er området kommer til å bli en katastrofe.
De sa faktisk, når du er distribusjon som ofte er systemet
så mye mer stabile, de faktisk kalle det tillit som en tjeneste.
Fordi når vi distribuere, vi har allerede gjort dette 9999 ganger.
Vi fikk dette.
>> Det gjør også det så mye enklere for dem å eksperimentere med ting.
Så hva de sa før er de brukes til å frigjøre til produksjons
hver uke eller hver måned.
Og dere kanskje tenk hvis du noensinne har
fikk en frist for en stor prosjekt du jobber med,
og du har denne listen over ting at du ønsker å få gjort,
og deretter som det blir nærmere fristen,
listen begynner å krympe litt.
Som vel, kanskje jeg gjør ikke virkelig trenger å gjøre dette.
Kanskje jeg egentlig ikke trenger å gjøre det.
>> Så det er hva de sa ville skje.
Som de ville komme nærmere release-- og det var en så stor avtale.
De måtte få utgivelsen ut i tide.
Men de ville starte paring bort funksjoner.
Og så de faktisk gjorde mindre funksjoner, fordi de var bare
slippe hver uke eller en måned.
Nå som de er frigjøring så mange ganger,
det gir dem denne fleksibiliteten å si, vet du hva?
Vi ønsker å bygge en ny funksjonen, men vi gjør ikke
vet om vi bør sette mye tid i det.
La oss sette ut dette virkelig minimum versjon av funksjonen
og se om noen klikker selv på det, hvis noen er enda interessert.
Hvis de er, så vi kan enten trekke den tilbake og bygge det ut,
eller vi kan veldig raskt legge til nye funksjoner til det.
>> Og så de sa det bare ga dem så mye mer fleksibilitet til å eksperimentere.
Og så er det veldig interessant å se større selskaper gjør det.
Og på en oppstart, spesielt der det er så viktig å vite hva som skjer,
det kan være veldig effektive.
Og deretter kommer tilbake til vår Kanban bord.
>> Det er interessant.
Mange ganger, når folk gjøre et styre som dette,
det er mye debatt om hva Ferdig kolonnen betyr.
Så OK, jeg jobber med en oppgave.
Er det gjort når sin kode fullføre?
Er det gjort når noen har anmeldt det og det føles som det er testet?
Er det gjort når det går ut i produksjon?
>> Og så mye startups vil si, vet du hva?
Vi kommer til å legge til en ny kolonne i her, som er en lærings kolonne.
Det er faktisk ikke gjort før vi har ikke bare satt i produksjon,
vi har satt det i kundenes hands-- men vi har faktisk
lært av hvordan de har brukt det.
Og hva er egentlig kult om det er da,
vi kommer til å innlemme det læring tilbake inn i syklusen,
og si basert på hva vi har lært, basert
på hva vi se-- hvordan vi ser dem bruke it-- vi kan finne ut det neste settet til å gjøre.
>> Så de er mønstre som jeg har sett for vellykket innovasjon
tvers av startups som har vært vellykket.
Jeg skulle også snakke litt om ressurser
som er tilgjengelig hvis du er interessert i å gjøre en oppstart iLab.
Men jeg kan også stoppe det her, hvis du Gutta har spørsmål om hva jeg snakket.
Holde det gående?
OK.
>> [Humrer]
>> OK, så vet du om iLab?
OK, awesome.
Så iLab har fantastisk ressurser.
Hvis du er ute etter å gjøre en oppstart, har vi noe
from-- vi gjør hacknights der.
Noen ganger gjør vi hackathons, hvis du bare ønsker
å gå hacke på kjølige prosjekter med folk.
>> Vi har workshops.
Vi har klasser som re for kreditt som er litt kult på entreprenørskap
som er åpne to-- mest av de som er åpne for alle.
Men vi har også gratis workshops et par ganger i uken,
at vi bare ta inn eksperter fra industrien
å snakke om anything-- fra tekniske begreper, til å samle inn penger,
til hvordan å gjøre salg.
>> Noe som du vil rundt startups, vi
har eksperter og beboere som er tilgjengelig for å gjøre en-mot-dem.
Du kan bare registrere deg for kontortid med dem.
Du trenger ikke engang å ha en oppstart.
Bare hvis du har ideer og du vil balance--
få informasjon eller innsikt fra en ekspert
på samme thing-- salg, finansiering.
Vi får juridisk hjelp.
Du kan registrere deg for dem der.
Vi har alltid fått ting skjer.
>> Så hvis du er interessert, det er en veldig stor ressurs.
Du kan gå til nettstedet vårt.
Nyhetsbrevet er virkelig fantastisk.
Jeg slags hater vanligvis får e-post, men det er kult.
Vi har så mye å gå på, jeg vet ikke engang hva alt det er.
Så hvis du registrerer deg for nyhetsbrevet, vil vi
fortelle deg hver uke hva som skjer.
Du kan også se på vår kalender for å se hvilke arrangementer som kommer opp.
>> Og jeg er der for å hjelpe hvis du ønsker å gjøre en tech oppstart.
>> [Humrer]
>> Så det er det jeg har.
>> [APPLAUSE]
>> [Ler]
>> Takk.