Kehitystiimin skaalautuminen ulkopuolisten insinöörien avulla koodin laatua menettämättä.

Johdanto

Tärkeimmät johtopäätökset

1. Käytä ulkoisia insinöörejä, kun roadmap on liian täynnä ydintiimillesi.
2. Aseta yksinkertaiset laatustandardit ja perusprosessi ennen heidän liittymistään.
3. Ota ulkoiset kehittäjät mukaan selkeällä tarkistuslistalla ja yhdellä tukihenkilöllä.
4. Käytä yhtä yhteistä sääntö-, arviointi- ja mittarijärjestelmää kaikille insinööreille.
5. Luota lyhyisiin kirjallisiin päivityksiin, jotta kasvava sekatiimi pysyy yhtenäisenä.

Miksi sinun pitäisi laajentaa kehitystiimiäsi ulkoisilla insinööreillä?

Kehitystiimiä kannattaa laajentaa ulkoisilla insinööreillä, kun roadmap on täynnä ja oma henkilöstö ei pysty pysymään mukana terveellä tavalla. Pääasia on yksinkertainen: ulkoisten insinöörien tulisi lisätä nopeutta ja osaamista ilman, että laatu kärsii. Jos he auttavat sinua toimittamaan vakaata työtä, jonka ylläpito tuntuu turvalliselta, järjestely on järkevä. Jos he vain lisäävät stressiä ja satunnaisia muutoksia, ajoitus on väärä.

Monet tuotantoyritysten johtajat kokevat saman paineen. Työmäärä kasvaa, määräajat venyvät ja hyvien insinöörien palkkaaminen omasta kaupungista vie kauan. Siinä vaiheessa alat miettiä insinööritiimin laajentamista ulkopuolisen avun avulla. Voit harkita ulkoistettua kehitystiimiä toisella alueella tai pienempää ryhmää, joka on lähempänä omaa aikavyöhykettäsi. Todellinen kysymys ei ole, voitko hankkia ulkopuolista apua, vaan milloin se tukee roadmapia sen sijaan, että peittää syvemmät ongelmat.

Yksi syy ulkoisten insinöörien kutsumiseen on pääsy taitoihin, joita sinulla ei tällä hetkellä ole talossa. Saatat tarvita lyhytaikaista tukea esimerkiksi data-, mobiilisovellus- tai uusien pilvipalveluiden alalla. Et ehkä halua rakentaa kokonaan uutta tiimiä jokaisen uuden aiheen ympärille. Siinä tapauksessa ohjelmistokehitystiimin laajentaminen voi tarjota sinulle joustavan tukikerroksen ydintiimisi ympärille. Pidät ydinosaamisen ja suunnan yrityksesi sisällä ja käytät ulkoista apua selkeisiin ja kohdennettuihin työtehtäviin. Arkielämässä tämä tuntuu enemmän kuin yhden rauhallisen asiantuntijan lisäämiseltä kiireiseen tiimiin kuin toisen yrityksen perustamiselta.

On myös hyvin perustavanlaatuinen aika- ja kustannusnäkökulma. Vahvojen ihmisten palkkaaminen voi viedä useita viikkoja tai jopa kuukausia, ja sinä aikana työruuhka ei katoa. Tässä voit nähdä selkeitä IT-henkilöstön vahvistamisen etuja. Voit tuoda lisäapua määrätyksi ajaksi ja määrätyllä laajuudella, samalla kun mietit pitkäaikaista rekrytointia. Joillekin tiimeille tämä vaihtoehto tasoittaa kysynnän huippuja sen sijaan, että se pakottaisi tekemään suuren hyppäyksen kiinteässä henkilöstömäärässä. Tällainen järjestely antaa sinun testata, mitä lisäkapasiteetti tuo tuotteellesi, ennen kuin muutat koko rakenteesi pysyvästi.

Voit myös valita erilaisia malleja sille, miten nämä henkilöt liittyvät tiimiisi. Henkilöstön lisäysmallissa lisäät ulkopuolisia insinöörejä omaan tiimiisi, ja johtajasi ohjaavat heidän työtään päivittäin. Nearshore-kehitystiimissä ihmiset sijaitsevat lähellä aikavyöhykettä ja voivat osallistua puheluihin ja chatteihin normaalina työaikana. Monet yritykset tekevät yhteistyötä kokeneen ohjelmistokehityskumppanin kanssa, joka jo osaa tehdä nearshore-ohjelmistokehitystä ja sulautua sisäisiin tiimeihin. Mitä lähempänä kulttuuri, aikavyöhyke ja työkalut ovat, sitä helpompi on saada monet ihmiset tuntemaan olevansa yksi tiimi, vaikka sopimukset olisivatkin erilaiset. Tämä yhteinen perusta tekee ulkoisesta työstä luonnollisen tuntuisen sen sijaan, että se tuntuisi epävakaalta.

Kuinka valmistelet koodipohjan ja prosessit ennen ulkoisen kehitystiimin lisäämistä?

Valmistaudut ulkoiseen kehitystiimiin asettamalla selkeän ja yksinkertaisen perustan tuotteen rakentamiselle ja toimittamiselle. Tarvitset yhteiset säännöt, perustyökalut ja näkyvän työskentelytavan ennen uusien ihmisten saapumista. Ilman tätä perustaa jokainen muutos riippuu henkilökohtaisesta tyylistä ja muistista, eikä uusilla ihmisillä ole mitään keinoa arvata oikeaa polkua. Tämän perustan avulla jopa uudet silmät voivat liikkua turvallisessa ja vakaassa rytmissä.

Voit ajatella tätä perustaa koodin laadun turvaavina suojakaiteina. Nämä suojakaiteet ovat yksinkertaisia tarkistuksia, jotka jokaisen muutoksen on läpäistävä riippumatta siitä, kuka sen on kirjoittanut. Ne voivat koskea esimerkiksi nimien antamista, tiedostojen muotoilua ja sitä, mitä "valmis" tarkoittaa pienissä työtehtävissä. Kun suojakaiteet ovat samat kaikille, tuotteesi tuntuu vakaalta, vaikka tiimi kasvaa ja muuttuu. Tämä helpottaa luottamusta koko prosessiin, ei vain jo tuntemiisi ihmisiin.

Tarvitset myös perustason jatkuvan integraation ja toimituksen putken. Tämä pitkä lause kuvaa yksinkertaista ideaa. Aina kun joku muuttaa koodia, järjestelmä suorittaa tarkistuksia ja auttaa siirtämään muutoksen käyttäjille pienin, turvallisin askelin. Tämä putki voi toimia yleisillä alustoilla ja se voi toimia jokaisen pääkoodivarastoon tekemäsi pushin yhteydessä. Toimiva putki muuttaa monet pienet muokkaukset selkeäksi etenemispoluksi sen sijaan, että ne muodostaisivat pelottavan suuren julkaisujen kasan. Uudet ihmiset voivat oppia tämän polun kerran ja sitten seurata sitä ilman ylimääräistä arvailua.

Testit ovat keskeinen osa tätä polkua. Automatisoitu testaus CI/CD:ssä tarkoittaa, että testit suoritetaan itsenäisesti aina, kun joku jakaa uuden koodin. Voit aloittaa yksinkertaisilla tarkistuksilla, jotka kattavat tuotteesi eniten käytetyt polut. Ajan myötä voit lisätä lisää testejä, kun huomaat, missä virheitä esiintyy. Pienikin joukko vakaita testejä tarjoaa enemmän turvallisuutta kuin valtava luettelo manuaalisia tarkistuksia, joita kukaan ei suorita ajoissa. Tämä lähestymistapa pitää asiat realistisina ja tukee sekä sisäisiä että ulkoisia insinöörejä.

Se auttaa myös tarkastelemaan järjestelmän vanhempia osia ennen kuin pyydät muita koskemaan niihin. Tässä tulee esiin tekninen velan hallinta. Tekninen velka on tapa kuvata koodia, joka toimii, mutta jota on vaikea muuttaa ilman riskiä. Voit merkitä alueet, jotka ovat turvallisia uusille ihmisille, ja alueet, jotka vaativat edelleen kokeneimman henkilöstön huomiota. Kun tiedät, missä riskialttiit osat sijaitsevat, voit ohjata ulkoisen kehitystiimin ensin turvallisemmille alueille. Tämä suojaa tuotettasi ja pitää uudet ihmiset poissa piilevistä ansista.

Perustan viimeinen osa on yksinkertainen turvallisuus ja pääsy. Turvallinen ohjelmistokehityksen elinkaari kuulostaa raskaalta, mutta se perustuu selkeisiin vaiheisiin. Annat ihmisille vain tarvitsemansa pääsyn, pidät todelliset käyttäjätiedot turvassa ja käsittelet salaisia avaimia huolellisesti. Kirjoitat myös muistiin, mitä tehdä, kun jokin menee pieleen, vaikka se olisi vain pieni asia. Kun turvallisuus on osa normaalia työtä, ulkoiset insinöörit voivat liittyä prosessiin ilman uusia pelkoja. Myös laki- ja turvallisuusosastosi näkevät, että tämä kasvu noudattaa suunnitelmaa, ei ole pikaratkaisu.

Miltä turvallinen perehdyttämissuunnitelma ulkoisille kehittäjille näyttää?

Turvallinen perehdyttämissuunnitelma ulkoisille kehittäjille antaa heille kontekstin, työkalut ja selkeät ensimmäiset askeleet ilman, että heitä kiirehditään syvään veteen. Sen pitäisi tuntua opastetulta polulta, jossa jokaisella päivällä on yksinkertainen ja todellinen tarkoitus. Kun suunnitelma on selkeä, uudet ihmiset voivat tuoda lisäarvoa viikkojen, ei kuukausien kuluessa, eikä oma tiimisi tunne olevansa uupunut jatkuvista kysymyksistä.

Ulkoisten kehittäjien perehdyttäminen alkaa yhteisellä näkemyksellä siitä, mitä heidän on opittava ensin. Tähän kuuluvat tuotteesi, käyttäjäsi ja tavanomainen työskentelytapasi. Kehittäjien perehdyttämisen tarkistuslista voi sisältää kaikki nämä asiat yhdessä paikassa. Se voi olla yksinkertainen asiakirja, jonka molemmat osapuolet voivat avata ja muokata. Näkyvä tarkistuslista muuttaa ajatuksen "Luulen, että olemme jo kertoneet heille tämän" ajatukseksi "Tiedämme tarkalleen, mitä on tehty ja mitä seuraavaksi". Tämä pieni muutos poistaa paljon hiljaista stressiä kaikilta.

Tässä on yksi yksinkertainen lista, joka toimii usein hyvin tällaisen tarkistuslistan pohjana:

1. Pääsy koodiin, työnseurantaan ja tärkeimpiin chat-huoneisiin.
2. Vaiheet tuotteen käyttämiseksi kannettavalla tietokoneella tai testipalvelimella.
3. Lyhyt opas käyttäjille, tärkeimmät prosessit ja keskeiset liiketoimintasäännöt.
4. Henkilöiden nimet, joilta voi kysyä tuotteesta, koodista ja työkaluista.
5. Kaksi tai kolme pientä, selkeää tehtävää, jotka ovat valmiita ensimmäistä todellista muutosta varten.

On myös hyödyllistä nimetä selkeä yhteyshenkilö. Tekninen johtaja tai vanhempi insinööri voi toimia perehdyttämisen tukihenkilönä ensimmäisten viikkojen ajan. Tämä henkilö voi tarkistaa kaikki varhaiset muutokset, vastata kysymyksiin ja selittää, miksi aiemmat valinnat ovat sellaisia kuin ovat. Lyhyet päivittäiset tarkistukset, jopa viiden minuutin chat-keskustelut, voivat pitää asiat raiteillaan. Rauhallinen kummi ja säännölliset yhteydenotot auttavat turvallisessa perehdyttämisessä enemmän kuin suuri puhe ensimmäisenä päivänä. Ajan myötä voit siirtää enemmän päivityksiä kehitystiimien asynkroniseen viestintään, kuten lyhyisiin kirjallisiin muistiinpanoihin.

Kokemukseni mukaan suurin riski perehdytyksen aikana on hiljainen hämmennys. Uudet työntekijät pelkäävät kysyvänsä liikaa, ja vanhat tiimin jäsenet toivovat, että asiat "klikkaavat" itsestään. Selkeä suunnitelma ulkoisten kehittäjien perehdyttämiselle ja yksi vastuuhenkilö kyseiselle suunnitelmalle muuttavat tämän kuvan. Kun yksi henkilö on vastuussa prosessista, voit havaita malleja, korjata heikkouksia ja tehdä jokaisesta seuraavasta perehdyttämiskierroksesta sujuvamman. Muutaman kuukauden kuluttua suunnitelmasta tulee toistettava voimavara sen sijaan, että se olisi uusi haaste joka kerta, kun tiimiin liittyy uusi jäsen.

Kuinka ylläpidät koodin laatua sekakehitystiimissä, kun hallinnoit ulkoisia kehittäjiä?

Koodin laatu ylläpidetään sekakehitystiimissä käyttämällä samoja yksinkertaisia sääntöjä, tarkistuksia ja lukuja kaikille. Standardien on koskettava kaikkia insinöörejä, jos haluat tuotteen tuntuvan yhtenäiseltä ja turvalliselta järjestelmältä. Kun jaat säännöt sopimustyypin mukaan, jaat myös luottamuksen ja selkeyden tiimissäsi.

Sekoitettu kehitystiimi on ryhmä, jossa sisäiset ja ulkoiset insinöörit työskentelevät saman tuotteen parissa. He voivat istua eri paikoissa, mutta heillä on yhteinen backlog ja koodivarasto. Tämä yhdistelmä voi olla erittäin vahva, koska se yhdistää syvällisen alan tuntemuksen ja tuoreita näkemyksiä. Se voi myös olla hauras, jos kukin ryhmä noudattaa omia tapojaan. Ilman selkeitä ohjeita tämä yhdistelmä muuttuu koodiklustereiksi, jotka tuntuvat erilaisilta ja joiden välillä on vaikea liikkua. Siinä vaiheessa laatu ja nopeus alkavat heikentyä.

Tässä auttavat yksinkertaiset koodin tarkistuksen parhaat käytännöt. Jokainen muutos tulisi tarkistaa vähintään yhden toisen henkilön toimesta, riippumatta siitä, kuka sen on tehnyt. Tarkistuksissa tulisi kiinnittää huomiota selkeyteen, turvallisuuteen ja sopivuuteen muun järjestelmän kanssa, ei vain tyyliin. Tätä voidaan tukea kevyillä työkaluilla, jotka skannaavat koodin yleisten ongelmien varalta. Nämä rutiinit pitävät ulkoisten kehittäjien koodin laadun linjassa muun tiimin kanssa rauhallisella, toistettavalla tavalla. Ihmiset oppivat toisiltaan ja rakentavat yhteisen käsityksen siitä, miltä "hyvä" näyttää.

Voit myös seurata pientä joukkoa ohjelmistokehitystiimin mittareita. Ne voivat osoittaa, kuinka kauan työn loppuun saattaminen kestää, kuinka monta ongelmaa käyttäjille tulee ja kuinka usein toimitat. Et tarvitse kymmeniä lukuja. Tarvitset vain muutaman, joita voit helposti lukea ja keskustella. Kun nämä mittarit pysyvät vakaina tai paranevat, kun hallinnoit ulkoisia kehittäjiä ja kasvatat tiimiä, tiedät, että järjestelysi tukee laatua. Jos ne heikkenevät, saat varhaisen signaalin tarkistaa sääntöjäsi, laajuutta tai tehtävien yhdistelmää.

Viestintätavat ovat yhtä tärkeitä kuin säännöt ja numerot. Monet sekakehitystiimit ovat myös hajautettuja ketteriä tiimejä, koska ihmiset työskentelevät useista paikoista tai aikavyöhykkeistä. Ne tarvitsevat kehitystiimeille asynkronista viestintää, jotta edistyminen ei riipu pitkistä puheluista. Lyhyet kirjalliset päivitykset, selkeät tehtävänmuistiinpanot ja yksinkertaiset tilatunnisteet auttavat paljon. Hyvät kirjalliset päivitykset helpottavat kaikkien insinöörien liittymistä, seuraamista ja tuotteen parantamista ajan mittaan. Live-keskustelut ovat edelleen tärkeitä, mutta ne eivät ole enää ainoa paikka, jossa päätöksiä tehdään.

Myös tapa, jolla otat ulkopuolisia ihmisiä mukaan, vaikuttaa laatuun. Jos kohtelet heitä erillisenä ryhmänä, jonka tavoitteet ovat epäselvät, he eivät tunne täyttä omistajuutta tuotteesta. Jos lisäät heidät olemassa oleviin ryhmiin yhden säännöstön alaisiksi, he voivat toimia kuten muutkin tiimin jäsenet. Jotkut yritykset käyttävät tähän tiimin laajennusta, jossa sisäiset ja ulkoiset ihmiset yhdistetään yhden johtajan alaisuuteen. Yhteiset tavoitteet, yhteiset työkalut ja yhteiset arvioinnit vaikuttavat ohjelmistokehityksen koodin laatuun enemmän kuin mikään raskas valvontadokumentti. Ajan myötä voit säätää ihmisten ja työn yhdistelmää, mutta yhteinen kehys pysyy samana.