On tavallista, että ohjelmistotuote siirtyy kehitystiimistä toiseen elämänsä aikana. Tuotteen eri vaiheet saattavat vaatia erilaista kehitystiimiä: konsultointia alkuperäisen version rakentamiseksi, a riippumaton kehittäjä sen ylläpitämiseksi sisäinen tiimi sen laajentamiseksi tai ammattimainen suunnittelija tekemään siitä visuaalisesti silmiinpistävän.

Huolimatta toistuvasta esiintymisestä, monet ei-tekniset perustajat ja tuotteiden omistajat ovat valmistautumattomia ja kamppailevat, kun on aika tuoda seuraava tiimi. Tämä johtaa usein uuden tiimin kyvyttömyyteen siirtyä nopeasti eteenpäin, ajanhukkaa ja turhautumista, johon kaikki jäsenet kuuluvat.

Jos tämä kuulostaa siltä, ​​että voisit olla sinä joko nyt tai tulevaisuudessa, sinun pitäisi olla jonkin verran huolissasi. Onneksi aion opastaa sinut läpi vaiheet valmistautuaksesi tähän mahdollisuuteen ja tekemään siirtymisestä mahdollisimman sujuvan.

Taskulampun ohittaminen: nouseminen uuteen kehitystiimiin

Tässä artikkelissa aion tarjota sinulle tarkistuslistan, joka auttaa sinua valmistautumaan tällaiseen muutokseen. Alat oppia tuntemaan tuotteesi läheisemmällä tasolla ja hallitsemaan paremmin siihen liittyviä eri palveluja ja tekniikoita, mikä auttaa sinua lähestymään uutta tiimiä suhteellisen helposti ja luottavaisesti.

Kun välität taskulampun uusille kehittäjille, varmista, että uusi vaihde ei pala.

Mutta entä jos et vaihda kaikkia laitteita? Pitäisikö sinun käyttää aikaa lukea tämä?

Vaikka jotkut edellisen tiimin jäsenistä pysyisivät aluksella, heillä ei ehkä ole kaikkia sujuvan siirtymisen edellyttämiä vastauksia ja tietoja. Vaikka ne voivat tarjota jatkuvuutta ja apua tiedonsiirtoprosessissa vanhalta tiimiltä uudelle, luottaminen nykyisen tiimin jäseniin ei korvaa sitä, että tuotteen omistaja ottaa haltuunsa ja helpottaa siirtoa. Jos et halua ottaa haltuunsa, se voi aiheuttaa kitkaa uusien ja vanhojen tiimin jäsenten välillä tai pitää vanhoja tiimin jäseniä tarpeettomien tehtävien päällä, mikä pakottaa heidät käyttämään liikaa aikaa viestintään uusien tiimin jäsenten kanssa ja ratkaisemaan erilaisia ​​ongelmia.

Jos jotkut tiimin jäsenet kuitenkin pysyvät aluksella, he voivat olla korvaamattomia siirtymävaiheessa. Tarkista heidän kanssaan, pidä heidät ajan tasalla ja yritä hyödyntää heidän asiantuntemustaan ​​tulvimatta heitä liikaa siirtymiseen liittyviä tehtäviä. Älä odota heidän tekevän kaikkea raskasta nostoa! Se on sinun tehtäväsi.

Joten ilman lisäkysymyksiä, mennään suoraan tähän!

Kerää dokumentaatio

Riippumattomia kehittäjiä pyydetään usein siirtymään olemassa olevaan koodikantaan, jota he eivät ole koskaan ennen nähneet. Tämä pätee erityisesti ApeeScape-ohjelmistoinsinööreihin. Tavoitteenamme on aina päästä toimintaan mahdollisimman pian, jotta voimme alkaa vaikuttaa myönteisesti asiakkaillemme.

Selkeän ja kattavan projektidokumentaation käyttö voi nopeuttaa huomattavasti käyttöönottoprosessia ja auttaa kehittäjiä välttämään virheitä, jotka voivat haitata edistymistä.

Hyvän dokumentaation tulisi kattaa ainakin seuraavat aiheet:

• Luo kehitysympäristö - Uuden työntekijän ensimmäinen tehtävä on asentaa sovellus ja suorittaa se omilla tietokoneillaan. Tämän tekeminen vaihtelee tekniikoittain. Yleensä se vaatii tehtäviä, kuten lähdekoodin hankkiminen, tietokannan luominen, riippuvuuksien asentaminen, ympäristön määrittäminen API-avaimilla ja tunnistetiedoilla, näytetietojen tuominen ja niin edelleen. Kehittäjillä on hyvä käsitys kaikesta tähän prosessiin liittyvästä asiasta omilla aloillaan, ja heidän on voitava säätää yksityiskohtia vastaavasti.
• Suorita automaattinen testipaketti - Kun näemme sovelluskortin testit, varmista, että kaikki on konfiguroitu oikein ja että seuraavat muutokset eivät riko mitään nykyisiä ominaisuuksia.
• Ota käyttöön vaiheistus- ja tuotantopalvelimille - Reaaliaikaisen sovelluksen päivittäminen uusilla muutoksilla on hyvin jäsennelty prosessi, ja näiden toimintojen järjestys tulisi hahmottaa askel askeleelta mahdollisimman yksityiskohtaisesti.
• Kaikki muut tiedot, jotka ovat merkityksellisiä aluksella olevalle uudelle kehittäjälle - Jokaisella sovelluksella on omat erikoisuutensa. Kirjoittamalla nämä oivallukset säästät tulevia joukkueita tarpeettomasti sellaisten ongelmien selvittämisessä, jotka edellinen joukkue on jo keksinyt korjata.

Hyvä dokumentaatio on onnistuneen siirtymän kulmakivi. Varmista, että uudella tiimilläsi on kaikki tarvitsemansa.

Dokumentaation tulee olla kehittäjän kirjoittama, jolla on omakohtaista kokemusta sovelluksen määrittämisestä ja osallistumisesta koodipohjaan.

Pyydä, että edellinen kehitystiimi helpottaa tiedonsiirtoa luomalla resurssin, joka koskettaa edellä mainittuja aiheita ennen siirtymistä.

Jos kirjoittaminen ei ole tiimin vahvuus, pyydä heitä tallentamaan yksi tai useampi kuvakaappaus, jotka osoittavat kehitysympäristön, käyttöönoton jne. Nykyään on jopa työkaluja, kuten Vagantti Y Satamatyöläinen jotka mahdollistavat täydellisten kehitysympäristöjen pakkaamisen ja jakamisen muille. Pohjimmiltaan, anna heille vasara sen sijaan, että opettaisit jotakuta vasaran rakentamisesta.

Lakmuskoe kuinka kattava ja tehokas projektidokumentaatio on, kuinka nopeasti uusi kehittäjä voi ymmärtää kehitysympäristönsä kokoonpanon ja sovelluksen suorituksen.

Ymmärrä tuotteesi

Suuri dokumentaatio ei vapauta sinua tarpeesta tuntea oman tuotteesi tekniikan perusteita. Ohjelmistotuotteen omistajana on sinun vastuullasi ymmärtää sovelluksesi mahdollisimman hyvin, vaikka sinulla ei olisikaan paljon teknistä tietämystä.

Ei teknistä taustaa? Ei ole tekosyytä olla ymmärtämättä projektisi peruskomponentteja kunnolla. Se voi maksaa sinulle kalliisti.

• Mitä teknisiä elementtejä sovelluksesi käyttää? - Siellä on monia yleisiä sovelluskehyksiä takaosa ja etupää , ja kaikkien uusien kehitystiimien tulisi tuntea sovelluksesi käyttötavat. Joitakin esimerkkejä back-end-verkkotekniikoista ovat Ruby on Rails , Node.js ja [Django] (https://en.wikipedia.org/wiki/Django_ (web_framework). Joitakin esimerkkejä käyttöliittymän verkkotekniikoista ovat React.js , Angular.js , Y Ember.js .
• Missä sitä isännöidään? - Eri verkkopalvelimilla on erilaiset käyttöönottoprosessit, jotka edellyttävät erilaista asiantuntemusta. Viime vuosina pilviteknologiat ovat luoneet useita uusia web-hosting-vaihtoehtoja, ja sinun on tunnistettava, mitä näistä käytät, ja kuvaile, miksi valitsit sen muiden sijaan.
• Mikä on kehitysprosessi? - Käyttääkö tiimisi tiettyä lähteenhallinnan työkalua, kuten [Git] (https://fi.wikipedia.org/wiki/Git_ (ohjelmisto)? Jos on, mikä on prosessi, jolla uusi ominaisuus on kehitetty, testattu , hyväksytty ja toteutettu? Prosessi olisi standardoitava, asianmukaisesti dokumentoitu ja uusien jäsenten on helppo toistaa niitä.
• Mitä kolmannen osapuolen palveluja sovelluksesi käyttää? - Jotkut sovellukset perustuvat kolmansien osapuolten palveluihin, kuten Shopify . Huomaa, että riippuvuus kolmansien osapuolten palveluista kasvaa vähitellen, ja vaikka et tällä hetkellä käyttäisikään lisäpalveluja, projekti saattaa päättää käyttää kolmannen osapuolen palvelua myöhemmin.
• Millä alustoilla sovelluksesi voi toimia? - Onko sovelluksesi työpöytäsovellus, verkkosovellus, reagoivat matkapuhelinsivustot, alkuperäinen iOS-sovellus, alkuperäinen Android-sovellus tai jokin muu? Toimiiko se useilla eri alustoilla? Mikä foorumi on prioriteettisi milloin tahansa? Millä alustalla tuotteesi on vahvin tai heikoin? Varmista, että tiedät kaikki sovelluksesi nykyisten alustojen yksityiskohdat ja jopa ne, joihin niitä voidaan laajentaa.

Ota hallussapito

Tämän päivän ohjelmistokehitysprosessi käyttää suurta määrää kolmansien osapuolten palveluja ja työkaluja. Tiedätkö sen vai et, hakemuksesi ei ole poikkeus.

Kehitystyön aikana vanha tiimisi on voinut rekisteröityä tai tilata puolestasi tai jopa käyttää omia tilejään saadakseen pääsyn tarvittaviin palveluihin. Siirtyminen uuteen tiimiin tarkoittaa, että sinun on otettava omistuksesi ja hallittava kaikkia palveluja ja työkaluja, joihin sovelluksesi perustuu, jotta voit sallia pääsyn uuteen tiimiin tarvitsematta käydä välittäjän tai mennä alkuperäisten kehittäjien jälkeen.

Seuraava luettelo näyttää erilaiset ulkoiset työkalut tai palvelut, joita sovelluksesi voi hyödyntää:

• Ohjaa lähteen hallintaa - GitHub , Bitbucket , Gitlab
• sivujen ylläpito - Heroku , Moottoripiha , Digitaalinen valtameri , Bluehost , Amazon-verkkopalvelut
• Tiedostojen isännöinti - Amazon-verkkopalvelut (S3)
• DNS-palveluntarjoaja - Hyvä isä , DNS yksinkertainen , Vie hiiri
• Kehityspalvelut - UusiRelic , FileStack , Segmentti , Bugsnag (ja monet muut)
• Maksupalvelut - Raita , Braintree , PayPal
• Blogipalvelut - WordPress , Tumblr , Aave
• Verkkokaupan ratkaisut - Shopify , Neliötila
• Analytics / seuranta - Google Analytics , Mixpanel , Kissmetrics
• Sähköpostimarkkinointi: MailChimp , Jatkuva yhteys

Kysy lähtevältä kehitystiimiltäsi, mitkä niistä soveltuvat. Pyydä kaikkia kehitystiimin omistamia palveluita siirtämään omistajuus sinulle. Jos se ei ole mahdollista, pyydä heitä auttamaan uuden tilin luomisessa ja varmista, että sovellus käyttää tiliäsi omansa sijaan. Tämän ei pitäisi edellyttää muuta kuin joidenkin määritysasetusten muuttamista sovelluksellesi. On sanomattakin selvää, että sinun on varmistettava, että jokainen kehityssopimus suojaa etujasi alusta alkaen ja varmistaa sujuvan siirtymisen tilanteesta riippumatta.

Valtuuta pääsy

Kun ymmärrät luotettavasti sovelluksesi ekosysteemin ja omistat sen käyttämät työkalut ja palvelut, voit nyt antaa täyden käyttöoikeuden saapuvalle tiimille tai jäsenelle.

Useimpien palveluiden avulla voit lisätä yhteiskäyttäjän tilillesi ja myöntää heille tietyn käyttöoikeuden. On okei olla konservatiivinen tässä tapauksessa, monet perustajat Yksittäiset omistajat haluavat erityisesti antaa kehittäjilleen järjestelmänvalvojille pääsyn palveluihinsa ja antaa heidän hoitaa kaiken. Tällä on sivuvaikutus, joka pitää sinut poissa silmukasta, mikä, kuten olemme oppineet, voi vaikeuttaa siirtymistä tulevaisuudessa.

Pitäisikö sinun antaa kehittäjillesi kaikki järjestelmänvalvojan oikeudet? Se on sinun tehtäväsi, useimmat ihmiset eivät näytä ajattelevan tämän lähestymistavan käyttöä. Suunnittele kuitenkin aina etukäteen ja varmista, että päätöksesi ei vaikuta negatiivisesti uuteen kehitystiimiin. Jos näin ei tehdä hankkeen alkuvaiheessa, voi olla ärsyttäviä seurauksia tulevaisuudessa.

Kanavanvaihdon hallinta

Nyt kun olet käsitellyt kaikki perusteet, sinun on hallittava siirtoa joukkueelta toiselle. Tässä on joitain perusvinkkejä sekä saapuvien että lähtevien joukkueiden kohtaamiseen.

Varmista, että hallitset projektisi luovutuksen teknisiä ja henkilökohtaisia ​​näkökohtia oikein. Anna uuden tiimisi tuntea olonsa kotoisaksi.

Saapuva joukkue

• Aseta odotukset - Uuden tiimin on tiedettävä tärkeimmät tavoitteesi, jotta he voivat keskittyä oikeaan suuntaan. On yhtä tärkeää hallita omia odotuksiasi siitä, mitä uusi tiimi voi saavuttaa heti.

• Tee säännöllisiä vierailuja - Älä jätä uutta joukkuetta kohtaloon. Sinun tulisi tehdä säännöllisiä tarkastuksia varmistaaksesi, että heillä on kaikki tarvitsemansa ja että he eivät tunne, että heidän on puolustettava itseään. Yritä tehdä tämä ilman tosiasiallista mikrohallintaa. Varmista, että he tietävät, että olet siellä tukemassa ja auttamassa, jos he sitä tarvitsevat, mutta älä paina heitä tarpeettomasti.

• Ole kärsivällinen - Kehittäjien sopeutuminen uuteen koodipohjaan vie aikaa. Ymmärrä, että on vähän aikaa oppimiseen, ennen kuin uusi joukkue saa kiinni vanhasta.

Lähtevä joukkue

• Kerää kaikki liikkeessä olevat koodit - Varmista, että kaikki lähdekoodit on rekisteröity päätietovarastoon ja että tiedät asennetun tilan tilan ja mikä ei. Uuden tiimin on tiedettävä tarkalleen mistä noutaa ja aloittaa työskentely. Olen itse kokenut tilanteen, jossa seurasin tiimin työtä, joka oli ottanut koodin käyttöön asettamatta sitä päätietovarastoon. Tämä johti virheisiin, päällekkäisiin töihin ja päänsärkyihin, jotka olisi voitu helposti välttää, jos lähtevä tiimi olisi jättänyt lähdekoodin yhtenäiseen tilaan.

• Päivitä käyttöoikeustaso - Jos he hajoavat hyvillä ehdoilla, kannattaa ehkä pitää heillä pääsy koodiin ja / tai käyttöönottoon. Monet joukkueet ovat halukkaita auttamaan siirtymävaiheessa, kunnes uusi joukkue voi täysin olettaa. Jos ei, harkitse käyttöoikeuden muuttamista tai peruuttamista, jotta vältät vahingossa syntyvät ongelmat tai ristiriidat uuden tietokoneen kanssa.

• Kiitos heidän työstään - Siirtymät voivat olla kiireisiä. Kun olet kiireinen uuden tiimin kanssa, älä unohda kiittää lähtevää tiimiäsi panoksesta projektiin.

johtopäätös

Jokainen muutos elämässä voi olla pelottavaa, mikä tuo epävarmuutta siitä, toimiiko se vai ei, pelkoa tuntemattomasta ja niin edelleen. Siirtyminen uuteen kehitystiimiin ei ole eroa, mutta voit ja sinun pitäisi ryhtyä toimiin helpottamiseksi. Useimmissa tapauksissa tarvitaan vain vähän pitkän aikavälin suunnittelua.

Parempi tekninen ja ei-tekninen käsitys ohjelmistotuotteestasi, kehitysprosessistasi ja kaikista prosessin vaiheista auttaa siirtymistä tiimistä toiseen mahdollisimman sujuvaksi ja kivuttomaksi.

Mikä parasta: Uusi tiimisi kunnioittaa sinua ja kiittää sinua valmistautumisesta! Se todennäköisesti säästää aikaa ja vaivaa, mikä tarkoittaa myös, että säästät rahaa. Lisäksi, mitä nopeammin uusi joukkue tajuaa vaatimuksen korkealla ammattitasolla, sitä parempi. Todennäköisesti he jatkavat näiden käytäntöjen toteuttamista saatuaan hallinnan projektista, joten myös seuraava siirtyminen on sujuvaa.

Tarkastellaan siis avainkohtia, jotka tulisi edeltää ohjelmistotuotteen omistajuuden siirtämistä:

• Kerää tai luo mahdollisimman paljon dokumentaatiota sovelluksestasi, kehitysympäristöstä ja käyttöönottoprosessista.
• Tunne tuotteesi sisältä ja ulkoa.
• Säilytä sovelluksesi kaikkien palvelujen ja kolmansien osapuolten riippuvuuksien hallinta ja omaa kaikelle käyttäjänimet ja salasanat.
• Ole valmis antamaan uudelle tiimillesi pääsyn kaikkeen, mitä he tarvitsevat pääsemään vauhtiin.
• Ole ennakoiva ja jätä mitään sattuman varaan tai lähtevälle kehitystiimille.