• Areng

Kuidas luua pühendunud arendusmeeskond 30 päevaga

  • Felix Rose-Collins
  • ••
  • 3 min read

Sissejuhatus

Enamik allhanke lepinguid ebaõnnestub juba esimesel kuul, mitte esimesel aastal. Insenerid on kvalifitseeritud ja tasu on õiglane, kuid meeskond veedab nädalaid ilma juurdepääsu, konteksti või selgete prioriteetideta. Kui töö lõpuks algab, on klient juba kaotanud usalduse selle mudeli vastu.

Pühendunud arendusmeeskond suudab saavutada täieliku tootlikkuse 30 päeva jooksul, kui klient on selleks valmis. Tarnija hoolitseb värbamise ja töölevõtmise eest, kuid ainult klient suudab selgitada toodet, koodibaasi ja äri eesmärke. Sisseelamine on ühine projekt ning suurem osa teadmiste edasiandmisest toimub kliendi poolt.

Enne esimest päeva: mida ette valmistada

Alustamiskuupäevale eelnev nädal määrab, kui kiiresti meeskond edasi liigub. Insenerid, kes peavad kolm päeva ootama juurdepääsu koodibaasile, kaotavad hoogu ja see viivitus annab tooni kogu koostööle.

Ettevalmistamine võtab kliendilt paar tundi aega. Suurem osa sellest on halduslik ja kogu nimekirjaga saab hakkama üks inimene.

  • Juurdepääs ja kontod. Looge kontod koodihoidlasse, ülesannete jälgimissüsteemi, pilvekonsooli ja suhtluskanalitesse. Testige iga sisselogimist enne alguskuupäeva.
  • Tehniline dokumentatsioon. Koguge arhitektuuriskeemid, API kirjeldused ja seadistusjuhendid ühte kohta. Vananenud dokumendid on vastuvõetavad, kui keegi märgib ära, mis on muutunud.
  • Kontaktisik. Määrake kliendi poolelt üks isik, kes vastab küsimustele ühe tööpäeva jooksul. See isik on tavaliselt tehniline juht või tooteomanik.
  • Esialgne töökogum. Valmistage ette 10–15 madala ja keskmise keerukusega ülesannet. Meeskond vajab tööd, mis aitab koodibaasiga tutvuda ilma tootmist ohustamata.

1. nädal: juurdepääs, kontekst ja esimesed ülesanded

Esimene nädal on pühendatud sisseelamisele. Meeskond õpib tundma, mida toode teeb, kes seda kasutab ja kuidas kood on korraldatud.

Selle nädala tulemus on kavandatult väike. Eesmärgiks on töökeskkonna loomine ja esimese muudatuse ühendamine, mitte uue funktsiooni väljalaskmine.

1.–2. päev: keskkonna seadistamine

Esimesel päeval korraldab klient alguskoosoleku. Tooteomanik selgitab ärimudelit, peamisi kasutajarühmi ja praeguseid prioriteete. Tehniline juht tutvustab arhitektuuri ja kasutuselevõtu protsessi.

Pärast kõnet seadistavad insenerid kohalikud keskkonnad ja käivitavad rakenduse. Enamik seadistamisprobleeme ilmneb just siin, seega peaks kliendi kontaktisik olema kättesaadav kiirete vastuste andmiseks.

3.–5. päev: esimesed väikesed ülesanded

Iga insener võtab esialgsest töökogumist ühe või kaks ülesannet. Selles etapis sobivad hästi veaparandused, väikesed kasutajaliidese muudatused ja testide katvuse suurendamine. Need puudutavad päris koodi, kuid on madala riskiga.

Iga ülesanne läbib täieliku tsükli, mis hõlmab koodi läbivaatamist, testimist ja kasutuselevõttu. See näitab meeskonnale, kuidas klient töötab, ning toob protsessi puudused varakult esile.

2. nädal: protsessid ja suhtlusrütm

Teisel nädalal liigub meeskond üksikülesannetelt meeskonna rutiinide juurde. Klient ja teenusepakkuja lepivad kokku, kuidas tööd planeeritakse, arutatakse ja millest aru antakse.

Meet Ranktracker

Kõik-ühes platvorm tõhusaks SEO-ks

Iga eduka ettevõtte taga on tugev SEO-kampaania. Kuid kuna on olemas lugematu hulk optimeerimisvahendeid ja -tehnikaid, mille hulgast valida, võib olla raske teada, kust alustada. Noh, ärge kartke enam, sest mul on just see, mis aitab. Tutvustan Ranktracker'i kõik-ühes platvormi tõhusaks SEO-ks.

Oleme lõpuks avanud registreerimise Ranktracker täiesti tasuta!

Loo tasuta konto

Või logi sisse oma volituste abil

Hajutatud meeskonnad vajavad rohkem struktuuri kui ühes kohas asuvad meeskonnad. Ajavööndid ja kultuurilised erinevused raskendavad mitteametlikku suhtlust, seega peab suhtlusrütm olema selgelt määratletud.

  • Igapäevased standup-koosolekud. Korraldage lühike kõne ajal, mil mõlemad ajavööndid kattuvad. 15 minutit on piisav olukorra ja takistuste arutamiseks.
  • Sprintide planeerimine. Planeerige töö ühe- või kahe nädala pikkuste sprintidena. Kliendi tooteomanik seab prioriteedid ja meeskond hindab töömahtu.
  • Koodi läbivaatamise reeglid. Lepige kokku, kes mida ja kui kiiresti läbi vaatab. Rohkem kui ühepäevane viivitus läbivaatamisel aeglustab kogu meeskonda.
  • Kirjalikud uuendused. Paluge jagatud kanalisse lühikest nädalakoondist. See annab huvirühmadele ülevaate ilma lisakoosolekuteta.
  • Eskaleerimisprotsess. Määrake kindlaks, kes lahendab takistused kummalgi poolel. Tarnija kliendihaldur tegeleb meeskonna probleemidega ja kliendi kontaktisik tootega seotud küsimustega.

3.–4. nädal: vastutus ja mõõtmine

Viimased kaks nädalat näitavad, kas sisseelamine õnnestus. Meeskond võtab endale tegeliku vastutuse ning mõlemad pooled hindavad tulemusi selgete kriteeriumide alusel.

See etapp näitab ka, kus protsessi tuleb veel kohandada. Väikeseid probleeme on 25. päeval lihtsam lahendada kui 90. päeval.

Tegelik funktsiooni üleandmine

Kolmandal nädalal määrake meeskonnale üks terviklik funktsioon toote arengukavast. See peaks nõudma disainilahendusi, hõlmama mitut koodibaasi osa ja tootmisesse viimist.

Kliendi tehniline juht vaatab tehnilise lähenemise läbi enne arendustöö algust. Pärast seda vastutab meeskond töö eest alates hinnangust kuni kasutuselevõtuni. Tihe järelevalve selles etapis on eesmärgiga vastuolus.

30. päeval jälgitavad näitajad

Kuu lõpus korraldage tarnijaga ülevaatamisvestlus. Võrrelge tulemusi esimesel nädalal seatud ootustega ja kasutage võimaluse korral numbreid.

  • Tarnetempo. Võrdle viimase kahe sprindi jooksul planeeritud ja täidetud story-punkte. Stabiilne tempo on olulisem kui kiire tempo.
  • Koodi kvaliteet. Kontrollige, kui suur osa pull-taotlustest läbib läbivaatuse esimesel või teisel ringil. Sagedased ümbertegemised viitavad kontekstis esinevatele lünkadele.
  • Küsimuste hulk. Jälgige, kui tihti insenerid paluvad kliendilt abi. See arv peaks iga nädal vähenema.
  • Huvirühmade tagasiside. Palu tooteomanikult ja tehniliselt juhilt lühikest hinnangut. Nende vaatenurk toob sageli esile probleeme, mida näitajad ei kajasta.

Tavalised sisseelamisvead

Enamikul sissejuhatusega seotud viivitustel on samad mõned põhjused. Ettevõtted kordavad neid, sest igaüks neist tundub alguses tühine.

  • Hilinenud juurdepääs. Kontod, mis saabuvad kolmandal päeval, maksavad meeskonnale kolm päeva. Turvalisuse heakskiitmine võtab sageli oodatust kauem aega, seega alustage sellega varakult.
  • Toote konteksti puudumine. Insenerid, kes ei mõista kasutajaid, teevad tehniliselt õigeid, kuid kasutud otsuseid. Üks tund toote selgitamist säästab nädalaid ümbertegemist.
  • Liiga palju kontaktisikuid. Kui viis inimest annab juhiseid, tekivad prioriteetide konfliktid. Üks otsustaja hoiab suuna selgena.
  • Meeskonna kohtlemine välisena. Eraldatud suhtluskanalid ja piiratud koosolekud loovad kaheastmelise struktuuri. Meeskonnad, kes integreeruvad kliendi rutiinidesse, sulanduvad kiiremini.

Lõppmõtted

30 päeva on piisav aeg, et pühendunud meeskond saavutaks täieliku tootlikkuse. Tulemus sõltub vähem tarnijast ja rohkem sellest, kui hästi klient on ette valmistanud juurdepääsu, konteksti ja selged prioriteedid.

Suhtuge sisseelamisse kui projekti, millel on vastutajad, tähtajad ja lõplik ülevaatus. Struktureeritud esimene kuu loob usalduse, mida pikaajaline koostöö vajab.

Felix Rose-Collins

Felix Rose-Collins

Ranktracker's CEO/CMO & Co-founder

Felix Rose-Collins is the Co-founder and CEO/CMO of Ranktracker. With over 15 years of SEO experience, he has single-handedly scaled the Ranktracker site to over 500,000 monthly visits, with 390,000 of these stemming from organic searches each month.

Alusta Ranktracker'i kasutamist... Tasuta!

Uuri välja, mis takistab sinu veebisaidi edetabelisse paigutamist.

Loo tasuta konto

Või logi sisse oma volituste abil

Different views of Ranktracker app