Tiimiprojektin kehittäminen vs. lentävä yksin

Tällä viikolla aloitan toisessa etätiimiprojektissani osana Chingu-ryhmiä. Tällöin haluaisin hetken pohtia sitä, mitä olen oppinut ensimmäisessä Voyage-kohortissa.

Kuva Andrew Neel Unsplash-kuvassa

Työskentely osana joukkuetta ei ole minulle jotain uutta. Olen viettänyt viimeiset 20 vuotta tutkimusta lääketeollisuudessa, jotka kaikki käytettiin erikokoisissa ja vuorovaikutustasoisissa joukkueissa. Tämä oli kuitenkin ensimmäinen kokemukseni osana kehitysryhmää ja se antoi uusia haasteita verrattuna oman hankkeen kehittämiseen.

Ryhmäni koostui kolmesta henkilöstä, joilla kaikilla oli kokemusta täyden pino-sovellusten kehittämisestä ja joista kahdella (ei minulla) oli kokemusta aikaisemmista ryhmäprojekteista Chingu: n kautta.

Tietenkin, projektiin suuntautuessa, minulla oli tavanomaisia ​​epäilyjä ja hermostuneita koodauksesta ryhmässä, kuten “Entä jos koodini ei vastaa tasoa muiden ryhmän kanssa?” Ja “Entä jos teen erehtyä ja tuhota kokonaan ryhmän koodikanta? ”ja niin edelleen…

Kuten tavallisesti, tällaiset epäilyt toimivat itsestään, kun aloimme syventyä projektiin, ja haluaisin ajatella, että kävelin pois paljon paremman kehittäjän siitä, että olen ollut osa sitä. Olen oppinut paljon muilta kahdelta ryhmän jäseneltä ja haluaisin ajatella, että he pystyivät oppimaan minulta jotain vastineeksi.

Kun mietin kokemusta kokonaisuutena, mielestäni oli kaksi avaintekijää, jotka vaikuttivat suuresti ryhmäprojektin etenemiseen ja yleiseen menestykseen, jotka eivät ole mukana yksittäisissä projekteissa, viestinnässä ja työnkulussa. Kuten alla näet, nämä elementit ovat hyvin toisiinsa liittyviä, mutta käsittelen niitä kutakin erikseen.

viestintä

Kun työskentelet itse projektin parissa, sinulla on aina täydellinen kuva projektisi laajuudesta ja tilasta. Jos et, niin on melko turvallista sanoa, että projektissasi on vakavia ongelmia…

Osana ryhmäprojektia olet kuitenkin riippuvainen joukkuetovereistasi tarjotaksesi sinulle kaikki muutokset, jotka he ovat tehneet (ja he ovat samassa riippuvaisia ​​sinusta).

Kuva James Sutton on Unsplash

Nämä viestinnät voivat olla eri muotoja, ja käsittelemme joitain niistä alla työnkulku-osiossa, mutta riittää todeta, että jos olet tehnyt muutosta projektiin etkä ole ilmoittanut siitä jollain tavalla joukkuetoverillesi, he eivät ole tietoisia siitä!

Mikä tarkoittaa, että he jatkavat omien tehtäviensä kanssa ikään kuin muutosta ei olisi tapahtunut. Tämä voi johtaa tarpeettomiin päänsärkyihin ja moniin tuhlattuihin tunteihin tiellä ... Kaikki nämä olisi voitu estää hyvällä kommunikaatiolla ryhmän jäsenten välillä.

Pinnalla tämä saattaa kuulostaa itsestään selvältä käsitteeltä, eikä se ole täysin syytä kirjoittaa (tai lukea) koko artikkelia aiheesta. Mutta jos olet tottunut työskentelemään yksin ja kaikenlainen viestintä tapahtuu alitajuisesti omassa päässäsi, tämä on kriittisesti tärkeä muutos normaalissa prosessissasi.

Sellaisenaan, varmista, että käytät kuin hyvä joukkuetoveri ja pidä kaikki silmukassa. Tämän ei tarvitse olla vaikeaa tai aikaa vievää. On todennäköistä, että joukkueesi on vakiinnuttanut viestintälinjat. Kaikkien pitäminen silmukalla voi olla yhtä helppoa kuin Trello-kortin tilan päivittäminen tai pikalinjan pudottaminen löysälle kanavalle.

Epäselvissä tapauksissa erehdy lisää viestinnän puolella.

Tarkoittaa, jos et ole varma siitä, onko jotain merkitystä joukkueelle, heitä vain nopea FYI sinne mihin tahansa kanavaan joukkue käyttää ja siirry eteenpäin.

Epäilen, että siellä on monia entisiä joukkueita, jotka sanovat "En voinut tehdä työtäni, kommunikaatioa tapahtui vain liian paljon!", Mutta siellä on paljon siellä sanomalla: "Tiimimme hajosi, koska kukaan ei kommunikoinut ...".

Työnkulku

Mikä vie meidät työnkulkuun.

Työnkululla tarkoitan sitä, kuinka ryhmäsi hallitsee git-prosessia ja jos he käyttävät tehokkaasti sivukonttoreita, sitoutuu, vetää pyyntöjä jne.

Kuten aiemmin totesin, tämä oli ensimmäinen ryhmäkehitysprojekti. Olin käyttänyt git: tä aikaisemmin soloprojekteissani, mutta minulla oli paljon opittavaa, kun piti käyttää gitiä osana joukkuetta.

Onneksi Francesco Agnoletto on kirjoittanut sarjan oppaita, joissa on selkeästi hahmoteltu kuinka git: ää tulisi käyttää joukkueympäristössä. Suosittelen lukemaan (ja kirjanmerkkejä tulevaa käyttöä varten) kaikki kolme artikkelia. Ne löytyvät täältä - osa 1, osa 2 ja osa 3.

Henkilökohtaisesti olen lukenut ne kumpikin useita kertoja ja ryhmämme käytti niitä pääsääntönä siitä, kuinka ryhmämme käsittelee työnkulkua.

En aio toistaa sitä, mitä Francesco on kirjoittanut artikkeleissaan, koska mielestäni hän kattaa materiaalin erittäin selkeästi, mutta haluan tuoda esiin useita huomautuksia, jotka hän esittää tämän artikkelin suhteen.

Ensinnäkin, kun se tehdään tehokkaasti, hyvä työnkulku parantaa ryhmäviestintää. Kuten aiemmin totesin, viestintä ja työnkulku ovat hyvin yhteydessä toisiinsa, ja kukin voi parantaa toisiaan.

Kuva Pavan Trikutam on Unsplash

Hyvän nimeämiskäytännön valitseminen (ja pitäminen kiinni) oksille antaa selvästi tiimikavereille tietää tarkalleen mitä työskentelet. Tämä yhdistettynä selkeisiin ja yksinkertaisiin otsikoihin tekemällesi tehtävälle tarjoaa paitsi suunnitellun versionhallinnan, myös kartan siitä, mitä jokainen joukkueen jäsen työskentelee (ja työskenteli).

Edellä mainituissa oppaissa on neuvoja molempien sivukonttoreiden ja sitoumusten nimeämiskäytännöistä. Lue ne!

Nyt kun olemme kaikki lukeneet Francescon artikkeleita ja olemme samalla sivulla työnkulun suhteen, haluaisin vielä esittää viimeisen huomautuksen. Ole varovainen, ettet tee muutoksia, jotka eivät kuulu alaan.

Tämä on erittäin tärkeää, eikä sitä voida aliarvioida! Kun työskentelet osana joukkuetta, älä tee muutoksia, jotka eivät kuulu sen toimialan piiriin, jolla työskentelet!

Rehellisyyden hengessä tämä on jotain, mikä minulla on huono tapa tehdä työskennellessäni sooloprojekteissa. Jos työskentelen yhden ominaisuuden kanssa ja muistan jotain, jonka tarkoitus oli muuttaa koodikannan toisessa osassa, menen vain vaihtamaan sitä huolehtimatta siitä, missä haarassa olen.

Vaikka tämä saattaa olla huono käytäntö, se ei todennäköisesti johda sinua liiallisiin ongelmiin yksin työskennellessäsi. Toisaalta tämän tekemisellä osana ryhmäprojektia voi olla erittäin huonoja seurauksia.

Koodimuutos, jolla yksi joukkuetoverisi työskentelee aktiivisesti (sen lisäksi, että he pilata heitä) voi aiheuttaa kaikenlaisia ​​konflikteja yrittäessään yhdistää muutokset. He saattavat viettää yhtä paljon aikaa yhdistämiskonflikttien ratkaisemiseen kuin he tekivät muutoksia haaraan ensinnäkin.

Ei hyvä joukkuedynamiikkaan ...

Yhteenveto

Jos aiot tehdä uran ohjelmistokehityksen ulkopuolella, sinun on opittava työskentelemään osana joukkuetta. Tämä on ehdottomasti yksi niistä pehmeistä taidoista, jotka voivat parantaa (tai estää) tehokkuuttasi kehittäjänä.

Sen ei tarvitse olla vaikeaa, se vie vain jonkin verran tietoista työtä. Pidä mielessä, että olet osa joukkuetta ja toimi sellaisenaan. Vahva viestintä ja työnkulku tekevät joukkueestasi suuremman kuin sen osien summa, mutta päinvastoin vetää ehdottomasti joukkueesi etenemisen pysähtymään.

Ja jos työskentelet tullaksesi kehittäjäksi, tee itsellesi palvelus ja tutkia Chingu-kohortteja. Se on mahtava globaali kehittäjäyhteisö ja haluttavat kehittäjät, jotka työskentelevät yhdessä tehdä suuria asioita.