Share
Det er en rekke viktige hensyn å gjøre når du jobber med premium WordPress-baserte prosjekter. Frem til dette punktet har vi tatt en titt på noen strategier for planlegging, bygging og markedsføring, men vi har ennå ikke sett på hva som kreves for å faktisk opprettholde en.
Tross alt er ingen programvareprosjekt fri for feil. Forutsatt at du genererer en betydelig brukerbase, vil kundene også ha ideer til funksjoner eller endringer de ønsker å se i et prosjekt. For det formål er det viktig å ha systemer på plass for å spore problemer, planlegge funksjoner og kommunisere med brukerne.
I dette siste innlegget i denne serien tar vi en titt på hvordan du best kan plassere prosjektet for langsiktig styring som fungerer bra for både deg og dine kunder.
Hvis du er en profesjonell utvikler, er du allerede klar over (og sannsynligvis oppnådd) minst ett kildekontrollsystem. Hvis det er tilfelle, kan denne delen være liten, men hvis du er relativt ny for utvikling og / eller kildekontroll, kan dette ende opp med å være en av de mest nyttige verktøyene du legger til i verktøykassen, ikke bare for dette prosjektet , men også i fremtiden.
Enkelt sagt, kildekontroll (noen ganger referert til som versjonskontroll) er en måte å holde en historisk oversikt over alle endringer som noen gang har gjort til en fil i prosjektet ditt.
Spesielt gir den deg muligheten til å ta stillbilder av koden din for utgivelse, tilbakestilling til tidligere versjoner av prosjektet, og gi notater om hva hver oppdatering oppnår. Hvis du jobber med et lag, kan du se hva hver person har bidratt til programmet, løse konflikter og slå sammen forskjeller.
Til slutt gir kildekontroll en måte for deg å opprettholde en historie med prosjektet ditt, administrere iterasjoner av arbeidet ditt, der du oppdaterer feil og introduserer nye funksjoner, og merker spesifikke versjoner for utgivelse.
Det finnes også en rekke forskjellige kildekontrollsystemer. Selv om detaljering av hvert system eller hvordan man bruker dem, er utenfor rekkevidden av denne serien, er det viktig å merke seg at det finnes en rekke gratis alternativer:
Hver plattform tilbyr sin egen andel av fordeler og ulemper. Snarere enn å bruke for mye tid på å diskutere hvilket system du skal velge, er du i en mye bedre posisjon å velge en og begynne å bruke den. Å ha noe på plass er bedre enn å ha ingenting på plass.
Som tidligere nevnt vil prosjektet bli lansert med feil. Uansett hvor mye tid du bruker til å teste og evaluere arbeidet ditt, er det nesten umulig å fange hvert eneste problem.
Siden du er Ikke kommer til å finne dem, brukerne dine vil, og du må være forberedt på å spore hva de finner. Søke etter en feilsporingsløsning kan være skremmende - markedet er rikt med alternativer.
Tidlig i prosjektet er det ingen grunn til å slippe mynt på en stor løsning. Du kan alltid skalere opp etter hvert som prosjektet ditt vokser. Effektiv feilsporing krever bare noen få funksjoner:
Det finnes en rekke gratis måter å spore bugs på - noen gammeldags, noen moderne webapplikasjoner:
Igjen, det er viktigere at du område sporing problemer snarere enn hvordan du sporer problemer og at du bruker disse problemene for å gjøre produktet enda bedre.
Hvis du har feil å spore (og du vil!), Så er det bare fornuftig at du tilbyr noen form for støtte til prosjektet ditt. Dessuten gir brukeren også et incitament til å kjøpe produktet (eller kjøpe en høyere nivå lisens) for at de vil ha noen "på ringen" for å svare på spørsmålene sine.
For hva det er verdt, ser jeg dette som gjensidig fordelaktig: Brukerne har noen tilgjengelig for å hjelpe dem med produktet ditt, du har kunder som gir tilbakemelding som hjelper deg med å øke arbeidet ditt.
Akkurat som med feilsporing er det dusinvis av støtteplattformer som strekker seg alt fra forsøkt og sant oppslagstavler til mer avanserte billettløsninger. Husk selv, vårt mål er å gjøre dette på det billige.
Etter hvert som prosjektet ditt vokser, kan du se på mer avanserte støtteprogrammer som skalere med arbeidet ditt.
For hva det er verdt, finner jeg at bruk av offentlige systemer som fora eller kommentarer betjener kundebunnen godt, fordi når du en gang kan svare en gang og har den tilgjengelig, har du dokumentasjon for hvordan du oppnår (eller løser) et problem med arbeidet ditt, og du har mulighet til å spore feil og funksjonsforespørsler fra brukerne dine.
Selv om denne delen er litt mer subjektiv, finner jeg at det er verdt å merke seg: Kunder elsker kommunikasjon. De vil vite at produktet de har kjøpt, er verdt pengene. Fordi WordPress-fellesskapet er så aktivt, er de vant til oppdateringer, noe som betyr at produktet ditt må holde seg oppdatert med plattformen.
En av de beste tingene du kan gjøre for kundene dine er å fortelle dem at du jobber med prosjektet - at det er i utvikling og at du hører på det de sier.
Selvfølgelig har du ikke lyst til å kommunisere. Her er et par måter å gi brukerne en oversikt over statusen til prosjektet uten å oversvømme dem med informasjon:
Vær oppmerksom på at alle de ovennevnte er måter brukerne kan logge på for å høre fra deg - du tvinger ikke informasjon om dem som de ikke vil høre. Det er enda en måte at du kan fortsette å gi kommunikasjon til brukerne uten å oversvømme dem med informasjon til det punktet å være irriterende.
Vi har fullført dekket alle stadier av planlegging, bygging, markedsføring og administrering av et premium WordPress-prosjekt på det billige. Forhåpentligvis har serien gitt noen vekkere som hjelper deg med ditt neste (eller nåværende) prosjekt.
Selvfølgelig er disse innleggene ikke uttømmende. Det er alltid mer å diskutere og mer å legge til, så vær så snill å legge til dine egne tanker i kommentarene!
Accentsconagua