Det er vanlig at et programvareprodukt overgår fra et utviklingsteam til et annet i løpet av livet. Forskjellige stadier av produktet kan kreve et annet utviklingsteam: et rådgivning for å bygge den første versjonen, a uavhengig utvikler å vedlikeholde det, et internt team for å skalere det opp, eller en profesjonell designer for å gjøre det visuelt slående.

Til tross for den hyppige forekomsten, er mange ikke-tekniske gründere og produkteiere uforberedte og sliter når det gjelder tid for å hente inn neste team. Dette resulterer ofte i manglende evne for det nye teamet til å gå raskt fremover, bortkastet tid og en frustrasjon som inkluderer alle medlemmer.

Hvis dette høres ut som det kan være deg, enten nå eller i fremtiden, bør du være noe bekymret. Heldigvis skal jeg gå gjennom trinnene for å forberede deg på denne eventualiteten og gjøre overgangen så smidig som mulig.

Passing the Torch: Gå ombord på et nytt utviklingsteam

I denne artikkelen skal jeg tilby deg en sjekkliste for å hjelpe deg med å forberede deg på en slik endring. Du begynner å bli kjent med produktet ditt på et mer intimt nivå og få større kontroll over de forskjellige tjenestene og teknologiene som følger med det, og hjelper deg å nærme deg et nytt team med relativt enkel og selvtillit.

Når du overfører fakkelen til nye utviklere, må du sørge for at nytt utstyr ikke brenner ut.

Men hva om du ikke bytter ut alt utstyret? Bør du ta deg tid til å lese dette?

Selv om noen medlemmer av forrige team forblir om bord, har de kanskje ikke alle svarene og informasjonen som er nødvendig for en jevn overgang. Selv om de kan gi kontinuitet og hjelp i kunnskapsoverføringsprosessen fra det gamle teamet til det nye, erstatter ikke å stole på medlemmer av det sittende teamet det faktum at produkteieren overtar og letter overføringen. Hvis du ikke kan overta, kan det føre til friksjon mellom nye og gamle teammedlemmer, eller holde gamle teammedlemmer på toppen av unødvendige oppgaver, og tvinge dem til å bruke for mye tid på å kommunisere med nye teammedlemmer og løse forskjellige problemer.

Imidlertid, hvis noen teammedlemmer blir om bord, kan de være uvurderlige i overgangsarbeidet ditt. Ta kontakt med dem, hold dem informert, og prøv å bygge videre på deres ekspertise uten å oversvømme dem med for mange overgangsrelaterte oppgaver. Ikke forvent at de skal gjøre alle tunge løft! Det er jobben din.

Så uten videre, la oss komme rett inn i dette!

Samle dokumentasjon

Uavhengige utviklere blir ofte bedt om å hoppe inn i en eksisterende kodebase som de aldri har sett før. Dette gjelder spesielt ApeeScape-programvareingeniører. Målet vårt er alltid å komme i gang så snart som mulig, slik at vi kan begynne å gi en positiv innvirkning på våre kunder.

Å ha tilgang til tydelig, omfattende prosjektdokumentasjon kan dramatisk øke hastigheten på ombordstigningsprosessen, og hjelpe utviklere med å unngå feil som kan hindre fremgang.

God dokumentasjon bør dekke minst følgende temaer:

• Lag et utviklingsmiljø - Den første oppgaven for enhver nyansatt er å installere applikasjonen og kjøre den på sine egne datamaskiner. Prosessen for å gjøre dette varierer mellom teknologiene. Generelt krever det oppgaver som å skaffe kildekoden, opprette databasen, installere avhengigheter, sette opp miljøet med API-nøkler og legitimasjon, importere eksempeldata og så videre. Utviklere har en god ide om alt relatert til denne prosessen innenfor sine respektive felt, og bør ha muligheten til å justere detaljene deretter.
• Kjør den automatiserte testpakken - Når vi ser testene av et søknadspass, sørger vi for at alt er konfigurert riktig, og at de neste endringene ikke bryter noen av de nåværende egenskapene.
• Distribuere til iscenesettelses- og produksjonsservere - Oppdatering av live-applikasjonen med de nye endringene er en svært strukturert prosess, og rekkefølgen på disse operasjonene bør skisseres trinnvis så detaljert som mulig.
• All annen informasjon som er relevant for en ny utvikler om bord - Hver app har sitt eget sett med særegenheter. Ved å skrive disse særegenheter, sparer du fremtidige lag unødvendig innsats for å feilsøke problemer som forrige team allerede har funnet ut hvordan de kan fikse.

God dokumentasjon er hjørnesteinen i enhver vellykket overgang. Sørg for at det nye teamet ditt har alt det trenger.

Dokumentasjon skal skrives av en utvikler som har førstehånds erfaring med å konfigurere applikasjonen og bidra til kodebasen.

Før noen overgang skjer, vennligst be om at det forrige utviklingsteamet legger til rette for kunnskapsoverføring ved å opprette en ressurs som berører emnene ovenfor!

Hvis skriving ikke er teamets sterke farge, kan du be dem ta opp et eller flere skjermbilder som viser oppsettet av utviklingsmiljøet, distribusjonen osv. I dag er det til og med verktøy som Vagrant Y Docker som lar komplette utviklingsmiljøer pakkes og distribueres til andre. I stedet for å instruere noen om hvordan man bygger en hammer, gi ham hammeren.

Lakmusprøven for hvor omfattende og effektiv prosjektdokumentasjon er, er hvor raskt en ny utvikler kan forstå konfigurasjonen av utviklingsmiljøet og applikasjonsutførelsen.

Forstå produktet ditt

Å ha god dokumentasjon avlaster deg ikke behovet for å kjenne til grunnleggende teknologier i ditt eget produkt. Som eier av et programvareprodukt er det ditt ansvar å forstå applikasjonen din så godt som mulig, selv om du ikke har mye teknisk kunnskap.

Ingen teknisk bakgrunn? Det er ingen unnskyldning for ikke å forstå de grunnleggende komponentene i prosjektet. Det kan koste deg dyrt.

• Hvilke teknologiske elementer bruker applikasjonen din? - Det er mange vanlige applikasjonsrammer for bakenden og frontenden , og ethvert nytt utviklingsteam bør være kjent med hva applikasjonen din bruker. Noen eksempler på back-end webteknologier er Ruby on Rails , Node.js , og [Django] (https://en.wikipedia.org/wiki/Django_ (web_framework). Noen eksempler på front-end webteknologier er React.js , Angular.js , Y Ember.js .
• Hvor er det vert? - Ulike webservere har forskjellige distribusjonsprosesser, som krever forskjellige nivåer av kompetanse. De siste årene har skyteknologier skapt en rekke nye alternativer for webhotell, og du må identifisere hvilke av disse, spesifikt du bruker og beskrive hvorfor du valgte det fremfor de andre.
• Hva er utviklingsprosessen? - Bruker teamet ditt et spesifikt kildekontrollstyringsverktøy som [Git] (https://en.wikipedia.org/wiki/Git_ (programvare)? I så fall, hva er prosessen der en ny egenskap er utviklet, testet , godkjent og implementert? Prosessen bør standardiseres, riktig dokumentert og lett å reprodusere av nye medlemmer.
• Hvilke tredjeparts tjenester bruker applikasjonen din? - Noen applikasjoner er basert på tredjeparts tjenester som f.eks Shopify . Vær oppmerksom på at avhengigheten av tredjeparts tjenester gradvis øker, og selv om du ikke bruker noen tilleggstjenester for øyeblikket, kan prosjektet ditt bestemme seg for å bruke en tredjepartstjeneste senere.
• På hvilke plattformer kan applikasjonen din kjøre? - Er applikasjonen din en stasjonær applikasjon, en webapplikasjon, responsive mobilnettsteder, native iOS-applikasjoner, native Android-applikasjoner eller andre? Kjører den på flere forskjellige plattformer? Hvilken plattform er din prioritet til enhver tid? På hvilken plattform er produktet ditt sterkest eller svakest? Forsikre deg om at du kjenner alle detaljene til de nåværende plattformene i applikasjonen din, og til og med hvilke de kan utvides til.

Ta besittelse

Dagens programvareutviklingsprosess bruker et stort antall tredjeparts tjenester og verktøy. Enten du vet det eller ikke, er søknaden ikke noe unntak.

I løpet av utviklingen kan det gamle teamet ditt ha registrert seg eller abonnert på dine vegne, eller til og med brukt sine egne kontoer for å få tilgang til nødvendige tjenester. Overgangen til et nytt team betyr at du må ta eierskap og ha kontroll over hver av tjenestene og verktøyene som søknaden din er basert på, slik at du kan gi tilgang til ditt nye team, uten å måtte gå gjennom en mellommann eller gå etter de opprinnelige utviklerne.

Følgende liste viser de forskjellige eksterne verktøyene eller tjenestene som applikasjonen din kan dra nytte av:

• Kontrollkildehåndtering - GitHub , Bitbucket , Gitlab
• Webhotell - Heroku , Motorhage , Digital Ocean , Bluehost , Amazon Web Services
• Filhotell - Amazon Web Services (S3)
• DNS-leverandør - Gå pappa , DNSenkelt , Sveve
• Utviklingstjenester - NewRelic , FileStack , Segmentet , Bugsnag (og mange andre)
• Betalingstjenester - Stripe , Braintree , PayPal
• Bloggtjenester - WordPress , Tumblr , Spøkelse
• E-handelsløsninger - Shopify , Squarespace
• Analytics / sporing - Google Analytics , Mixpanel , Kissmetrics
• Epost markedsføring: MailChimp , Konstant kontakt

Spør ditt utgående utviklingsteam hvilke som gjelder. For noen av tjenestene som eies av utviklingsteamet, be dem overføre eierskapet til deg. Hvis det ikke er mulig, kan du be dem om å hjelpe deg med å opprette en ny konto og sørge for at appen bruker kontoen din i stedet for deres. Dette bør ikke kreve noe mer enn å endre noen konfigurasjonsinnstillinger for applikasjonen din. Det sier seg selv at du må sørge for at hver utviklingskontrakt beskytter interessene dine fra første dag og sikrer en jevn overgang, uansett situasjon.

Autoriser tilgang

Med en solid forståelse av app-økosystemet ditt og eierskap til de forskjellige verktøyene og tjenestene det bruker, kan du nå gi full tilgang til det innkommende teamet eller medlemmet.

Med de fleste tjenester kan du legge til en samarbeidspartner på kontoen din og gi dem et visst tilgangsnivå. Det er greit å være konservativ i denne saken, mange grunnleggere Eneeiere foretrekker spesielt å gi utviklerne sine administrator tilgang til tjenestene sine og få dem til å håndtere alt. Dette har bieffekten av å holde deg utenfor løkken, som vi har lært kan gjøre overgangen vanskeligere i fremtiden.

Bør du gi utviklerne dine full administratorrettigheter? Det er opp til deg, de fleste synes ikke å ha noe imot å bruke denne tilnærmingen. Du bør imidlertid alltid planlegge fremover og sørge for at avgjørelsen din ikke påvirker et nytt utviklingsteam negativt. Unnlatelse av å gjøre det i de tidlige stadiene av prosjektet kan få irriterende konsekvenser i fremtiden.

Administrere overleveringen

Nå som du har dekket alle basene, må du administrere overgangen fra ett lag til et annet. Her er noen grunnleggende tips for å møte både innkommende og utgående team.

Sørg for at du håndterer de tekniske og personlige aspektene ved prosjektoverleveringen på riktig måte. La det nye teamet ditt føle deg som hjemme.

Innkommende team

• Sett forventninger - Det nye laget må vite hva de viktigste målene dine er, slik at de kan fokusere i riktig retning. Å håndtere dine egne forventninger til hva det nye teamet kan oppnå med en gang er like viktig.

• Gjør regelmessige besøk - Ikke overlat det nye laget til skjebnen. Du bør foreta hyppige kontroller for å sikre at de har alt de trenger, og at de ikke føler at de må klare seg selv. Prøv å gjøre dette uten å mikromanagere. Sørg for at de vet at du er der for å støtte og hjelpe hvis de trenger det, men ikke legg unødvendig press på dem.

• Vær tålmodig - Det tar tid for utviklere å tilpasse seg en ny kodebase. Forstå at det vil være litt læretid før det nye laget kan ta igjen det gamle.

Utgående team

• Samle all koden i omløp - Forsikre deg om at all kildekode er registrert i hovedregisteret, og at du vet status for hva som er distribuert og hva som ikke er. Det nye teamet må vite nøyaktig hvor de skal hente og begynne å jobbe. Selv har jeg opplevd en situasjon der jeg fulgte arbeidet til et team som hadde distribuert kode uten å legge den i hovedregisteret. Dette førte til feil, duplisering av arbeid og hodepine som lett kunne vært unngått hvis det utgående teamet hadde forlatt kildekoden i en konsistent tilstand.

• Oppdater tilgangsnivået - Hvis de brøt sammen på gode betingelser, vil du kanskje beholde dem med tilgang til koden din og / eller distribusjonen. Mange lag er villige til å hjelpe i overgangsfasen, til det nye laget fullt ut kan anta. Hvis ikke, bør du vurdere å endre eller tilbakekalle tilgangen for å unngå utilsiktede problemer eller konflikter med den nye datamaskinen.

• Takk for deres arbeid - Overganger kan være hektiske. Mens du er opptatt med det nye teamet, ikke glem å takke det utgående teamet for deres bidrag til prosjektet.

konklusjon

Enhver overgang i livet kan være skummelt, noe som gir usikkerheten om det vil fungere eller ikke, frykten for det ukjente og så videre. Overgangen til et nytt utviklingsteam er ikke annerledes, men du kan og bør ta skritt for å gjøre det lettere. I de fleste tilfeller er det bare behov for litt langsiktig planlegging.

Å ha en større teknisk og ikke-teknisk forståelse av programvareproduktet ditt, utviklingsprosessen og alle tingene som gikk inn i prosessen, vil bidra til å gjøre enhver overgang fra ett team til et annet så smidig og smertefri som mulig.

Best av alt: Ditt nye team vil respektere deg og takke for at du er forberedt! Det vil sannsynligvis spare deg for tid og krefter, noe som også betyr at du sparer penger. Dessuten, jo raskere det nye teamet innser insisteringen på et høyt profesjonelt nivå, jo bedre. De vil mest sannsynlig fortsette å implementere denne praksisen når de tar kontroll over prosjektet, så neste overgang vil også være jevn.

Så la oss se gjennom de viktigste punktene som skal gå foran enhver overføring av eierskap til programvareproduktet ditt:

• Samle inn eller lag så mye dokumentasjon som mulig om applikasjonen din, utviklingsmiljøet og distribusjonsprosessen.
• Kjenn produktet ditt innvendig og utvendig.
• Opprettholde kontrollen over alle tjenester og tredjepartsavhengigheter i applikasjonen din, og ha brukernavn og passord for alt.
• Vær forberedt på å gi ditt nye team tilgang til alt de trenger for å komme i gang.
• Vær proaktiv og la ingenting være tilfeldig, eller til det utgående utviklingsteamet.