Technologas #10: Kaip metiniuose pokalbiuose rasti daugiau prasmės?

Vaidas

Vaidas, CTO

Buon giorno! Tęsiant kitokius Technologus, man vis norisi toliau plėtoti temas apie sklandų, ramų ir efektyvų darbą IT srityje. Praeitą kartą kalbėjau apie programuotojų našumo matavimą, o šįsyk panarpliokime susijusią temą – metinius pokalbius su IT žmonėmis. 

Metiniai jie yra ne veltui – per tokį laiką uždera krūva darbinių temų, kurias verta išgvildenti, o ir viena kita nuoskauda atsiranda. Susitikimą suplanuojame, žmones surenkame, pokalbį pravedame ir… išeiname supratę, kad nieko nesupratome. Pažįstama situacija?

Idealiame pasaulyje viskas paprasta

Mintyse deliojant metinį pokalbį kaip ir viskas aišku: įvertinsime darbuotojo našumą, pažiūrėsime, kaip patobulėjo žmogus, prie atlyginimo pridėsime kokį vieną kitą 💶, aptarsime, kad kitais metais, žinoma, jis augs dar labiau, papasakosime apie įmonės rezultatus... Super, išeis darbuotojas įkvėptas ir laimingas, nes supras viską tiek apie save, tiek apie UAB!

O kaip būna iš tikrųjų?

Idealias situacijas modeliuoti lengva, bet realus gyvenimas dažnai pasisuka kiek kitaip. Ko gero, visi esame patyrę, kad išėjus iš ilgai laukto pokalbio taip ir neateina tas nušvitimas. Ar pajutote, kad jau šį kartą pilnai pažinote savo įmonę? Ar buvote patenkinti savo rezultatų įvertinimu? Ar žinote, kaip ateityje dirbti geriau?

Kad ir kaip keistai skambėtų – mano paties našumo niekas niekada dorai nėra įvertinęs. Nesupraskite neteisingai, aš turėjau pokalbių. Tiksliau, pokalbių bandymus. Kodėl tik bandymus? Nes pasitaikydavo tokios tradicinės situacijos:

  • Nulis specifikos. Interviu vykstantis su žmogumi, kuris neturi jokios idėjos, ką tu veiki ir kokie darbai šiuo metu yra atliekami, neturės prasmės. Jei paprašęs situacijų pavyzdžių sulauki tylos arba temos nukreipimo, žinok, kad įėjai į pirmo nulio zoną;
  • Tau lieja pagyras, o tu didžiuojiesi savimi. Išeini iš pokalbio ir viskas atrodo gerai: saulė šviečia, gėlės žydi, oras kvepia! Bet grįžus namo pradedi galvoti: apie ką buvo šitas pokalbis? Pradedi analizuoti, ką išgirdai, ir be pagyrų nelieka nei vieno žodžio. Dar blogiau būna, kai tokiu pat principu ne giria, o peikia;
  • Tu didžiuojiesi, ką padarei paskutiniu metu. Bet tai niekaip nėra pastebima kitos pusės. Ir kodėl? Gal tiesiog pamiršo? Bandai kažkaip įterpti, užsiminti, bet visos pastangos atsiduria šiukšlių dėžėje;
  • Yra ir daugybė kitų klaidų, apie kurias jau plačiai aprašyta šaltiniuose.

Ne kartą pravedęs metinį pokalbį esu ir pats esu supratęs, kad padariau panašių klaidų. Ir aš ruošdavausi tam pokalbiui, ir ruošdavosi kita pusė. Bet kartais išlįsdavo toks 👻, kuris pradėdavo kramtyti motyvaciją, kol galiausiai nelikdavo nei vienos entuziazmo 🍒.

Idealias situacijas modeliuoti lengva, bet realus gyvenimas dažnai pasisuka kiek kitaip. Ko gero, visi esame patyrę, kad išėjus iš ilgai laukto pokalbio taip ir neateina tas nušvitimas.

Kokius aspektus aptarti būtina?

Ieškodamas sprendinių, kaip tuos vaiduoklius išvaikyti, sau įsivardijau, jog gerame pokalbyje turėtų būti paliesti keli esminiai aspektai. Vertinant iš programuotojo perspektyvos, tikėčiausi šių temų:

  • Konkretumas. Pokalbyje turi dalyvauti žmogus, kuris žino įmonės projektus ir klientus, su kuriais man tenka dirbti dieną iš dienos. Tuomet, kai būna pikta/liūdna/džiugu dėl jų, norėčiau pasidžiaugti ar pasiguosti. Be to, jis turėtų žinoti komandą, kurioje greičiausiai yra ir mano palaikymo reikalaujantys žmonės, ir kiti man svarbūs asmenys;
  • Kodas. Taip pat, jis turi būti peržiūrėjęs mano darytus pull-requestus + atsinešęs informacijos, kur, ką, kada aš darau ne taip. Tai gali būti ne tas pats žmogus, bet turi turėti grįžtamojo ryšio ir apie tai, kodėl aš esu;
  • Motyvacija. Net jei aš padariau neteisingų dalykų, pokalbyje turi būti paliečiama, ką reikėtų taisyti, o ne bandoma pabrėžti mano klaidas;
  • Retrospektyva. Aš dėčiau = ženklą tarp komandos retrospektyvos ir našumo vertinimo. Iš esmės šie abu dalykai siekia atsakyti į tą patį klausimą – ką padaryti, kad komandai/klientui/bendradarbiams būtų geriau dirbti. Kaip išsinešame action pointus iš retrospektyvos, taip ir čia ieškome jų.

5 pagrindiniai žingsniai, įnešantys aiškumo

Na, o dabar paverskime platesnes idėjas į konkrečius žingsnius, kaip iš metinio pokalbio išsinešti kuo daugiau naudos:

1. Prieš pokalbį reikėtų peržiūrėti bandymus sujungti PR’us (pull-request). Svarbiausia tai, kad ši dalis yra tęstinė ir jai tinkamai pasiruošti reikia nemažai laiko (man visada tokiose situacijose praverčia užrašai). Reikėtų atkreipti dėmesį į: 

  • Stiliaus klaidas: ten, kur darydavau daugiausiai klaidų ir jas rasdavo mano kolegos, ar dabar jau neberanda?
  • Kodo supratimas. Kaip dabartinis kodas atrodo lyginant su senuoju, t.y. ar jis geresnis? Ar man suprantama verslo logika? Ar ji įgyvendinama teisingai?
  • Kodo kokybė. Ar aš pradėjau rašyti testus? Ar tie testai yra reikšmingi? Ar reikiamus dalykus testuoju? Kaip per laiką kinta mano testai?
  • Pasikeitimas. Kaip aš, parašęs kodo gabalą, suprantu, kad tai sprendžia biblioteka/karkasas, ir ką aš su šiuo kodu padarau? Ar aš jį palieku, ar keičiu?
  • Šalutiniai efektai. Ar mano kodas reikalauja šalutinių įrankių? Ar jie yra prieinami visose aplinkose? Ar būtų problemų, jei norėčiau išiungti/pakeisti jį?
  • Ar dažnai būna taip, kad at’revertiname funkcionalumą, nes jis veikia ne taip gerai, kaip tikėjomės? Ar dažnai tai būna produkcinėje aplinkoje?
  • Kodo peržiūros. Ar aš atlieku ne tik stiliaus peržiūrą? Ar dažnai parašau komentarų? Koks santykis komentarų apie stilių ir visų kitų? 

2. Savarankiškas mokymasis. Ar aš dedu papildomai pastangų? Ar dalinuosi šiomis žiniomis? Apie tai geriausiai pakomentuos komandos nariai, tad reikėtų jų ir paklausti. 

3. Techniniai pasiūlymai. Šioje vietoje patarimo ieškoti reikėtų pas projektų vadovą arba mane supančius techninius žmonės.

4. Atsakomybės. Reikėtų pasigilinti, ar aš atlieku savo darbus iki galo, net jei tai reikalauja padirbėti šiek tiek ilgiau. Ar aš lengvai pasiekiamas visais kanalais?

5. Komunikacija ir atgalinio ryšio davimas. Čia viena sudėtingiausių dalių man pačiam, kurioje jaučiuosi silpnas, bet tikiuosi, kad patarimų gausiu iš jūsų.

Praktikoje sunkiau nei teorijoje

Tiesa, objektyviai atsakyti į šiuos klausimus gali būti nelengva, o kur dar visi žmogiškieji elementai, trukdantys pamatyti tą tikrąjį vaizdą. Ir pats jaučiu, kad ieškodamas šių atsakymų su savo komanda ne vienoje vietoje turiu gerokai pasistengti. Na, bet tobulėjimas yra nuolatinis procesas, o kol kas tikiuosi, kad šis trumpas sąrašas padės jums artimiausią pokalbį kilstelėti į truputį aukštesnį lygį ir iš jo išsinešti ne tik padidintą atlyginimą.

Kaip visuomet, būtų smagu išgirsti ir apie jūsų metinių pokalbių patirtis, failus ir veiksmingas strategijas.

Vaidas

Vaidas, CTO

Technologijų entuziastas, nuolat ieškantis būdų, kaip optimizuoti procesus ir kaip atrasti dar neišbandytą naminio sidro skonį.