Kā 30 dienās iekļaut darbā specializētu izstrādes komandu

Ievads

Lielākā daļa ārpakalpojumu līgumu izgāžas jau pirmajā mēnesī, nevis pirmajā gadā. Inženieri ir kvalificēti un samaksa ir taisnīga, taču komanda nedēļām ilgi strādā bez piekļuves, konteksta vai skaidrām prioritātēm. Līdz brīdim, kad darbs beidzot sākas, klients jau ir zaudējis uzticību šim modelim.

Speciāli izveidota izstrādes komanda var sasniegt pilnu ražīgumu 30 dienu laikā, ja klients tam ir sagatavojies. Piegādātājs nodrošina darbinieku atlasi un nodarbināšanu, taču tikai klients var izskaidrot produktu, kodbāzi un biznesa mērķus. Darba uzsākšana ir kopīgs projekts, un lielāko daļu zināšanu nodošanas veic klienta puse.

Pirms pirmās dienas: kas jāsagatavo

Nedēļa pirms sākuma nosaka, cik ātri komanda strādās. Inženieri, kuri trīs dienas gaida piekļuvi repozitorijam, zaudē darba sparu, un šī kavēšanās nosaka visas sadarbības toni.

Sagatavošanās prasa no klienta dažas darba stundas. Lielākā daļa no tām ir administratīva, un vienai personai var uzticēt visu sarakstu.

• Piekļuve un konti. Izveidojiet kontus koda repozitorijam, uzdevumu izsekošanas rīkam, mākoņkonsolē un saziņas kanāliem. Pirms sākuma datuma pārbaudiet katru pieteikšanos.
• Tehniskā dokumentācija. Vienā vietā apkopojiet arhitektūras diagrammas, API aprakstus un uzstādīšanas rokasgrāmatas. Novecojuši dokumenti ir pieņemami, ja kāds atzīmē, kas ir mainījies.
• Kontaktpersona. Norīkojiet vienu personu klienta pusē, kas atbild uz jautājumiem vienas darba dienas laikā. Parasti šī persona ir tehniskais vadītājs vai produkta īpašnieks.
• Sākotnējais uzdevumu saraksts. Sagatavojiet 10 līdz 15 uzdevumus ar zemu un vidēju sarežģītības pakāpi. Komandai ir nepieciešams darbs, kas ļauj iepazīt kodu bāzi, neradot risku ražošanas procesam.

1. nedēļa: piekļuve, konteksts un pirmie uzdevumi

Pirmā nedēļa ir veltīta orientācijai. Komanda uzzina, ko dara produkts, kas to lieto un kā ir organizēts kods.

Šajā nedēļā paredzētais rezultāts ir neliels. Mērķis ir izveidot darba vidi un veikt pirmo apvienoto izmaiņu, nevis izlaist jaunu funkciju.

1.–2. diena: Vides konfigurēšana

Pirmajā dienā klients organizē sākuma sanāksmi. Produkta īpašnieks izskaidro biznesa modeli, galvenās lietotāju grupas un pašreizējās prioritātes. Tehniskā vadītāja izklāsta arhitektūru un ieviešanas procesu.

Pēc sarunas inženieri konfigurē lokālās vides un palaida lietojumprogrammu. Lielākā daļa konfigurācijas problēmu parādās šajā posmā, tāpēc klienta kontaktpersonai jābūt pieejamai, lai sniegtu ātras atbildes.

3.–5. diena: pirmie nelielie uzdevumi

Katrs inženieris uzņemas vienu vai divus uzdevumus no sākotnējā uzdevumu saraksta. Šajā posmā labi der kļūdu labojumi, nelielas lietotāja saskarnes izmaiņas un testu pārklājums. Tie skar reālo kodu, bet rada nelielu risku.

Katrs uzdevums iziet pilnu ciklu — koda pārskatīšanu, testēšanu un ieviešanu. Tas parāda komandai, kā strādā klients, un savlaicīgi atklāj trūkumus procesā.

2. nedēļa: Procesi un komunikācijas ritms

Otrajā nedēļā komanda pāriet no individuāliem uzdevumiem uz komandas rutīnu. Klients un pakalpojuma sniedzējs vienojas par to, kā darbs tiek plānots, apspriests un par to tiek sniegti pārskati.

Attālinātām komandām ir nepieciešama stingrāka struktūra nekā komandām, kas strādā vienā vietā. Laika zonas un kultūras atšķirības apgrūtina neformālo saziņu, tāpēc saziņas ritmam jābūt skaidri noteiktam.

• Ikdienas stand-up sanāksmes. Rīkojiet īsu tālruņa sarunu laikā, kas pārklājas abos laika joslās. 15 minūtes ir pietiekami, lai apspriestu statusu un šķēršļus.
• Sprintu plānošana. Plānojiet darbu viena vai divu nedēļu sprintos. Klienta produkta īpašnieks nosaka prioritātes, un komanda novērtē nepieciešamo darba apjomu.
• Koda pārskatīšanas noteikumi. Vienojieties par to, kurš ko pārskata un cik ātri. Pārskatīšanas kavēšanās, kas ilgst vairāk nekā vienu dienu, palēnina visu komandu.
• Rakstiskas atjauninājumu ziņas. Lūdziet, lai kopīgajā kanālā tiktu publicēts īss iknedēļas kopsavilkums. Tas nodrošina ieinteresētajām pusēm pārskatāmību bez papildu sanāksmēm.
• Eskalācijas ceļš. Noteikt, kurš katrā pusē atrisina šķēršļus. Piegādātāja klientu menedžeris risina komandas jautājumus, bet klienta kontaktpersona — jautājumus par produktu.

3.–4. nedēļa: Atbildība un novērtēšana

Pēdējās divās nedēļās tiek pārbaudīts, vai ievadapmācība ir bijusi veiksmīga. Komanda uzņemas reālu atbildību, un abas puses izvērtē rezultātus, balstoties uz skaidriem kritērijiem.

Šis posms arī parāda, kur procesā vēl nepieciešamas korekcijas. Nelielas problēmas ir vieglāk novērst 25. dienā nekā 90. dienā.

Reālas funkcijas nodošana

Trešajā nedēļā komandai jāuzdod izstrādāt viena pilnīga funkcija no produkta attīstības plāna. Tai jāprasa dizaina lēmumi, darbs ar vairākām kodbāzes daļām un izlaišana ražošanā.

Pirms izstrādes sākšanas klienta tehniskā vadība izvērtē tehnisko pieeju. Pēc tam komanda ir atbildīga par darbu no tā novērtēšanas līdz ieviešanai. Cieša uzraudzība šajā posmā ir pretrunā mērķim.

Rādītāji, kas jāuzrauga 30. dienā

Mēneša beigās rīkojiet pārskata sarunu ar piegādātāju. Salīdziniet rezultātus ar pirmajā nedēļā izvirzītajām cerībām un, ja iespējams, izmantojiet skaitļus.

• Piegādes temps. Salīdziniet plānotos un pabeigtos stāstu punktus pēdējos divos sprintos. Stabils temps ir svarīgāks par ātru tempu.
• Koda kvalitāte. Pārbaudiet to pull pieprasījumu īpatsvaru, kas iztur pārskatīšanu pirmajā vai otrajā kārtā. Bieža pārstrādāšana liecina par trūkumiem kontekstā.
• Jautājumu skaits. Sekojiet līdzi, cik bieži inženieri lūdz palīdzību klientam. Šim skaitam katru nedēļu vajadzētu samazināties.
• Ieinteresēto pušu atsauksmes. Lūdziet produkta īpašniekam un tehniskajam vadītājam sniegt īsu novērtējumu. Viņu viedoklis bieži atklāj problēmas, kuras rādītāji neuzrāda.

Bieži sastopamas kļūdas ieviešanas procesā

Lielākajai daļai ieviešanas kavējumu ir vieni un tie paši cēloņi. Uzņēmumi tos atkārto, jo sākumā katrs no tiem šķiet nenozīmīgs.

• Novēlota piekļuve. Konti, kas tiek atvērti trešajā dienā, komandai izmaksā trīs dienas. Drošības apstiprinājumi bieži vien aizņem vairāk laika, nekā gaidīts, tāpēc sāciet tos savlaicīgi.
• Produkta konteksta trūkums. Inženieri, kuri nesaprot lietotājus, pieņem tehniski pareizus, bet bezjēdzīgus lēmumus. Viena stunda, kas veltīta produkta izskaidrošanai, ietaupa vairākas nedēļas pārstrādāšanai.
• Pārāk daudz kontaktpersonu. Ja norādījumus sniedz pieci cilvēki, rodas prioritāšu konflikts. Viens lēmumu pieņēmējs nodrošina skaidru virzienu.
• Komandas uztveršana kā ārēju vienību. Atsevišķi saziņas kanāli un ierobežotas sanāksmes rada divlīmeņu struktūru. Komandas, kas iekļaujas klienta ikdienas darbā, integrējas ātrāk.

Nobeiguma domas

Trīsdesmit dienas ir pietiekami, lai specializēta komanda sasniegtu pilnu produktivitāti. Rezultāts ir mazāk atkarīgs no piegādātāja un vairāk no tā, cik labi klients sagatavo piekļuvi, kontekstu un skaidras prioritātes.

Uztveriet ievadapmācību kā projektu ar atbildīgajiem, termiņiem un galīgo pārskatu. Strukturēts pirmais mēnesis veido uzticību, kas nepieciešama ilgtermiņa sadarbībai.