Taustaa
Pysy rauhallisena ja siirry uuteen kehitystiimiin
On tavallista, että ohjelmistotuote siirtyy kehitystiimistä toiseen sen elinkaaren aikana. Tuotteen eri vaiheet saattavat edellyttää erityyppistä kehitystiimiä: konsultointia alkuperäisen version rakentamiseksi, yksin freelance-kehittäjä sen ylläpitämiseksi, yrityksen sisäinen tiimi, joka tuo sen mittakaavassa, tai ammattimainen suunnittelija, joka lisää 'popia'.
Huolimatta siitä, kuinka usein tämä tapahtuu, monet ei-tekniset perustajat ja tuotteiden omistajat kokevat olevansa valmistautumattomia ja sekaisin, kun on aika tuoda seuraava joukkue. Tämä johtaa usein siihen, että uusi tiimi ei kykene edistyä nopeasti, tuhlaa aikaa ja turhautumista kaikille mukana oleville.
Jos tämä kuulostaa siltä, että voisit olla sinä joko nyt tai tulevaisuudessa, sinun pitäisi olla jonkin verran huolissasi. Onneksi aiomme käydä läpi vaiheet, jotka voit tehdä valmistautuaksesi tähän mahdollisuuteen ja tekemään siirtymisestä mahdollisimman sujuvan.
Taskulampun ohittaminen: Uuden kehitystiimin aloittaminen
Tässä artikkelissa annan sinulle tarkistuslistan kohteista, jotka auttavat sinua valmistautumaan tällaiseen muutokseen. Opit tuntemaan tuotteesi läheisemmällä tasolla ja saamaan entistä paremman hallinnan kaikista sen tekemiseen liittyvistä palveluista ja tekniikoista, mikä antaa sinulle mahdollisuuden nousta uuteen tiimiin luottavaisin mielin ja suhteellisen helposti.
Mutta entä jos et korvaa koko tiimiä? Pitäisikö sinun vaivautua lukemaan tätä?
Vaikka jotkut edellisestä joukkueesta pysyisivät aluksella, heillä ei ehkä ole kaikki sujuvan siirtymisen edellyttämät vastaukset ja tiedot. Vaikka ne voivat tarjota jatkuvuutta ja apu Tietojen siirtämisessä vanhalta tiimiltä uudelle, luottaminen vakiintuneisiin tiimin jäseniin ei korvaa sitä, että tuotteen omistaja ottaa vastuun ja helpottaa siirtoa. Lisäksi vastuun laiminlyönti voi aiheuttaa kitkaa vanhojen ja uusien tiimin jäsenten välillä tai rasittaa vanhoja tiimin jäseniä tarpeettomilla tehtävillä, pakottaen heidät tuhlaamaan liikaa aikaa uusien tiimin jäsenten kanssa viestimiseen ja erilaisten ongelmien ratkaisemiseen.
Silti, jos jotkut tiimin jäsenet pysyvät aluksella, he voivat olla korvaamaton voimavara siirtymävaiheessa. Keskustele heidän kanssaan, pidä heidät ajan tasalla ja yritä hyödyntää heidän kokemustaan tulvimatta heitä liian moniin siirtymiseen liittyviin tehtäviin. Älä odota heidän tekevän kaikki raskas nosto! Se on sinun tehtäväsi.
Joten ilman lisäkysymyksiä, sukelkaamme sisään!
Kerää dokumentaatio
Freelance-kehittäjiä pyydetään usein siirtymään olemassa olevaan kooditietokantaan, jota he eivät ole koskaan ennen nähneet. Tämä pätee erityisesti ApeeScape-ohjelmistoinsinööreihin. Tavoitteenamme on aina saada vauhti mahdollisimman nopeasti, jotta voimme alkaa vaikuttaa myönteisesti asiakkaisiimme.
Projektin selkeän ja perusteellisen dokumentaation saaminen voi nopeuttaa huomattavasti aloitusprosessia ja auttaa kehittäjiä välttämään kaatumisia, jotka voivat estää etenemistä eteenpäin.
Hyvän dokumentaation on katettava ainakin seuraavat aiheet:
- Kehitysympäristön luominen - Ensimmäinen tehtävä kaikille uusille tulokkaille on saada sovellus käynnistymään omilla tietokoneillaan. Menettely vaihtelee tekniikan mukaan. Yleensä se vaatii tehtäviä, kuten lähdekoodin hankkiminen, tietokannan asettaminen, riippuvuuksien asentaminen, ympäristön määritys API-avaimilla ja tunnistetiedoilla, näytetietojen tuominen ja niin edelleen. Kehittäjillä on hyvä idea kaikesta tähän prosessiin liittyvästä asiasta omilla aloillaan, ja heidän pitäisi pystyä säätämään yksityiskohtia vastaavasti.
- Suorita automaattinen testipaketti - Sovelluksen testikortin katsominen varmistaa, että kaikki on määritetty oikein ja että tulevat muutokset eivät riko mitään nykyisiä ominaisuuksia.
- Käyttöönotto lavastus- ja tuotantopalvelimille - Live-sovelluksen päivittäminen uusimmilla muutoksilla on erittäin komentosarjaprosessi, ja näiden toimintojen järjestys tulisi hahmottaa vaihe vaiheelta mahdollisimman yksityiskohtaisesti.
- Kaikki muut tiedot, jotka ovat merkityksellisiä uudelle kehittäjälle - Jokaisella sovelluksella on omat erikoisuutensa. Niiden kirjoittaminen säästää tulevia joukkueita paljon hukkaan kuluneissa ongelmien virheenkorjausongelmissa, joita edellinen joukkue on jo keksinyt käsitellä.
Dokumentaation tulee kirjoittaa kehittäjä, jolla on henkilökohtainen kokemus sovelluksen määrittäminen ja koodikantaan osallistuminen.
Pyydä ennen siirtymää, että edellinen kehitystiimi helpottaa tiedon siirtämistä luomalla resurssin, joka koskettaa yllä olevia aiheita!
Jos kirjoittaminen ei ole heidän vahvuutensa, pyydä heitä tallentamaan yksi tai useampi kuvaruutu, jotka osoittavat kehitysympäristön asennuksen, käyttöönoton jne. Nykyään on jopa työkaluja, kuten Vagantti ja Satamatyöläinen joiden avulla kokonaiset kehitysympäristöt voidaan pakata ja jakaa muille. Pohjimmiltaan, anna heille vasara sen sijaan, että annat jollekulle ohjeita vasaran rakentamisesta.
Lakmuskoe projektin dokumentoinnin kattavuudelle ja tehokkuudelle on se, kuinka nopeasti uusi kehittäjä voi saada kehitysympäristönsä asetukset ja käyttämään sovellustasi.
Ymmärrä tuotteesi
Suuri dokumentaatio ei vapauta sinua tarvitsemasta tuntea oman tuotteesi tekniikan perusteita. Ohjelmistotuotteen omistajana on sinun vastuullasi ymmärtää sovelluksesi mahdollisimman hyvin, vaikka et olisikaan kovin tekninen.
Seuraavat kysymykset ovat yleisiä, ja sinun pitäisi odottaa tietävän vastaukset etsimättä niitä:
- Mitä tekniikkapinoa sovelluksesi käyttää? - Ohjelmalle on monia yhteisiä sovelluskehyksiä käyttöliittymä ja käyttöliittymä , ja kaikilla uusilla kehitystiimeillä on oltava perehtynyt sovelluksesi käyttämiin. Joitakin esimerkkejä back-end-verkkotekniikoista ovat Ruby on Rails , Node.js ja Django . Joitakin esimerkkejä etupään verkkoteknologioista ovat React.js , Angular.js ja Ember.js .
- Missä sitä isännöidään? - Eri web-isännöillä on erilaiset käyttöönottoprosessit, jotka edellyttävät vaihtelevaa kokemusta. Viime vuosina pilviteknologiat ovat luoneet useita uusia isännöintivaihtoehtoja, ja sinun on tunnistettava käyttämäsi vaihtoehto ja kuvattava, miksi se on valittu muiden sijasta.
- Mikä on kehitysprosessi? - Käyttääkö tiimisi tiettyä lähteenhallinnan työkalua, kuten Mennä ? Jos on, mikä on prosessi, jolla uusi ominaisuus kehitetään, testataan, hyväksytään ja otetaan käyttöön? Prosessi on standardoitava, asianmukaisesti dokumentoitu , ja tulokkaat voivat helposti kopioida niitä.
- Mitä kolmannen osapuolen palveluja sovelluksesi käyttää? - Jotkut sovellukset on rakennettu kolmannen osapuolen palveluihin, kuten Shopify . Muista, että riippuvuus kolmansien osapuolten palveluista kasvaa vähitellen, ja vaikka et tällä hetkellä käytä mitään ylimääräistä palvelua, projektisi saattaa päättää käyttää kolmannen osapuolen palvelua joskus myöhemmin.
- Millä alustoilla sovelluksesi voi toimia? - Onko sovelluksesi työpöytäsovellus, verkkosovellus, reagoiva mobiilisivusto, alkuperäinen iOS-sovellus, alkuperäinen Android-sovellus tai jotain muuta? Toimiiko se useilla eri alustoilla? Mikä foorumi on prioriteettisi kulloinkin? Millä alustalla tuotteesi on vahvin ja heikoin? Muista tietää kaikki sovelluksesi nykyisten alustojen yksityiskohdat ja jopa ne, joihin sitä voidaan laajentaa.
Ottaa omistukseen
Tämän päivän ohjelmistokehitysprosessi hyödyntää lukemattomia kolmannen osapuolen palveluita ja työkaluja. Tiedätkö sen vai et, hakemuksesi ei ole poikkeus.
Kehitystyön aikana edellinen tiimisi on voinut rekisteröityä puolestasi tai jopa käyttää omia tilejään saadakseen tarvitsemansa palvelut. Siirtyminen uuteen tiimiin tarkoittaa, että sinun on otettava omistuksesi ja hallittava kaikkia palveluja ja työkaluja, joihin sovelluksesi luottaa, jotta voit antaa pääsyn uudelle tiimillesi tarvitsematta käydä läpi välittäjää tai jahdata alas. alkuperäiset kehittäjät.
Seuraava on luettelo erilaisista ulkoisista työkaluista tai palveluista, joita sovelluksesi saattaa käyttää:
- Lähteen hallinnan hallinta - GitHub , Bitbucket , Gitlab
- Sivujen ylläpito - Heroku , Moottoripiha , Digitaalinen valtameri , Bluehost , Amazon-verkkopalvelut
- Tiedostojen ylläpito - Amazon-verkkopalvelut (S3)
- DNS-palveluntarjoaja - Hyvä isä , DNS yksinkertainen , Vie hiiri
- Kehityspalvelut - UusiRelic , FileStack , Segmentti , Bugsnag (ja lukemattomat 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ä, mitkä niistä ovat sovellettavissa. Kaikille palveluille, jotka ovat omistettu kehitystiimi, pyydä heitä siirtämään omistajuus sinulle. Jos se ei ole mahdollista, pyydä heitä auttamaan sinua luomaan uusi oma tili ja varmista, että sovellus käyttää tiliäsi omansa sijaan. Tämän ei pitäisi edellyttää muuta kuin joidenkin sovelluksen kokoonpanoasetusten muuttamista.
On sanomattakin selvää, että jokainen kehityssopimus suojaa etujasi alusta alkaen ja takaa sujuvan siirtymisen riippumatta siitä, mistä tahansa.
Myönnä pääsy
Kun ymmärrät luotettavasti sovelluksesi ekosysteemin ja omistat kaikki sovelluksesi käyttämät työkalut ja palvelut, voit nyt tarjota täyden pääsyn saapuvalle tiimille tai henkilölle.
Useimpien palveluiden avulla voit lisätä yhteiskäyttäjän tilillesi ja myöntää heille tietyn käyttöoikeustason. On okei olla konservatiivinen täällä . monet perustajat, erityisesti yksinyrittäjät, antavat kehittäjilleen mieluummin täyden järjestelmänvalvojan pääsyn palveluihinsä ja saavat heidän käsittelemään kaiken. Tällä on kielteinen 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 puhelusi, eikä useimmilla ihmisillä ole ongelmia tämän lähestymistavan kanssa. Sinun on kuitenkin aina suunniteltava etukäteen ja varmistettava, 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 kaikki tukikohdat on katettu, sinun on hallittava kanavanvaihto joukkueelta toiselle. Tässä on joitain perusvinkkejä sekä saapuvan että lähtevän ryhmän kanssa.
Saapuva joukkue
- Aseta odotukset - Uuden tiimin tulisi tietää, mitkä ovat tärkeimmät tavoitteesi, jotta he voivat keskittyä oikeaan suuntaan. On yhtä tärkeää hallita omia odotuksiasi siitä, mitä uusi tiimi voi saavuttaa heti.
- Kirjaudu sisään usein - Älä jätä uutta joukkuetta uppoamaan tai uimaan. Haluat kirjautua sisään usein varmistaaksesi, että heillä on kaikki tarvitsemansa, etkä tunne, että heidän on puolustettava itseään. Yritä tehdä tämä ilman mikrohallintaa. Varmista, että he tietävät, että olet siellä tukemassa ja auttamassa tarvittaessa, mutta älä paina heitä tarpeettomasti.
- Ole kärsivällinen - Kehittäjien mukautuminen uuteen koodipohjaan vie aikaa. Ymmärrä, että oppimiseen kuluu jonkin aikaa, ennen kuin uusi joukkue pystyy vastaamaan edellisen joukkueen tahtiin.
Lähtevä joukkue
- Kerää kaikki jäljellä olevat koodit - Varmista, että kaikki lähdekoodit on tarkistettu päätietovarastoon ja että tiedät asennetun aseman tilan. Uuden tiimin on tiedettävä tarkalleen mistä noutaa ja aloittaa työskentely. Olen itse kokenut tilanteen, jossa otin tehtävän tiimille, joka oli ottanut koodin käyttöön asettamatta sitä päätietovarastoon. Tämä johti virheisiin, päällekkäiseen työhön ja päänsärkyihin, jotka olisi voitu helposti välttää, jos lähtevä tiimi jätti lähdekoodin yhtenäiseen tilaan.
- Päivitä heidän käyttöoikeustasonsa - Jos erositte hyvillä ehdoilla, saatat haluta antaa heille pääsyn koodiin ja / tai käyttöönottoon. Monet joukkueet auttavat mielellään siirtymävaiheessa, kunnes uusi joukkue voi ottaa sen kokonaan vastaan. Jos ei, harkitse käyttöoikeuden alentamista tai peruuttamista, jotta vältytään tahattomilta ongelmilta tai ristiriidoilta uuden tiimin 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 projektiisi.
Johtopäätös
Jokainen muutos elämässä voi olla pelottavaa, mikä tuo epävarmuutta sen onnistumiseksi, pelkoa tuntemattomasta ja niin edelleen. Siirtyminen uuteen kehitystiimiin ei ole eroa, mutta voit ja sinun pitäisi ryhtyä toimiin helpottamiseksi. Useimmissa tapauksissa se vaatii vain vähän pitkäaikaista suunnittelua.
Parempi tekninen ja ei-tekninen käsitys ohjelmistotuotteestasi, kehitysprosessistasi ja kaikista prosessin vaiheista auttaa tekemään siirtymisen tiimistä toiseen mahdollisimman saumattomaksi ja kivuttomaksi.
Mikä parasta, uusi tiimisi kunnioittaa ja kiittää sinua pelisi kärjessä! Säästät todennäköisesti heille aikaa ja vaivaa, mikä tarkoittaa myös, että säästät rahaa. Lisäksi, mitä nopeammin uusi tiimi tajuaa vaativansa korkeita ammatillisia vaatimuksia, sitä parempi. Mahdollisuudet ovat, että he jatkavat näiden käytäntöjen toteuttamista, kun he ottavat projektin haltuunsa, mikä tekee myös seuraavasta siirtymisestä sujuvan.
Tarkastellaan siis avainkohtia, jotka tulisi edeltää ohjelmistotuotteen omistajuuden siirtämistä:
- Kerää tai luo niin paljon dokumentaatiota kuin mahdollista sovelluksestasi, kehitysympäristöstä ja käyttöönottoprosessista.
- Tunne tuotteesi sisältä ja ulkoa.
- Säilytä hallinta kaikki sovelluksesi kolmannen osapuolen palveluista ja riippuvuuksista, ja sinulla on käyttäjänimet ja salasanat kaikkeen.
- Ole valmis antamaan uudelle tiimillesi pääsyn kaikkeen, mitä he tarvitsevat päästäksesi liikkeelle.
- Ole ennakoiva ja jätä mitään sattuman varaan tai lähtevälle kehitystiimille.
