KODĖL sunku vertinti užduočių atlikimo laiką?

Neseniai gavau klausimą: „Pastaruoju metu susiduriu su problema, IT žmogus negali/nenori tiksliai nusakyti per kokį terminą atliks darbus. Jo atsakymai visada dviprasmiai… pastoviai turiu „pušinti” kad gaučiau laiką ir datą. Ar jūs turite tokių bėdų?” Mano atsakymas buvo – turėjome, bet jau nebeturime.

Pradėjus naudoti Scrum tiek Lavasoft‘e tiek Adform‘e gauti užduočių laiko įvertinimus iš komandos narių buvo nemažas iššūkis ir man. Tačiau dabar, užduočių apimtis (net ir labai didelių) įsivertiname per dažniausiai valandą trunkantį, kas dvi savaites vykstantį, produkto užduočių smulkinimo (Product Backlog Grooming) susirinkimą. Kaip mums tai pavyko? Pradėjau aš nuo priežasčių suradimo: kodėl kolegoms taip sunkiai sekėsi su vertinimu.

Nemokėjimas

Pirmiausiai man paaiškėjo, jog dauguma darbuotojų tiesiog nemokėjo to daryti. Daugeliu atvejų užduotys žmonėms buvo paduodamos jau įvertintos projektų vadovų. Kartais, užduotis tiesiog buvo paskiriama, ir žmogus prie jos dirbdavo „kiek prireiks”. Taigi ir vienu ir kitu atveju, užduočių vertinimas buvo projektų vadovų darbas, kartais pasitariant su vyresniaisiais specialistais. Blogiausia, kad dažniausiai tie vyresnieji specialistai nedalyvaudavo pačiame užduoties vykdyme, tad netgi jie nesužinodavo ar jų įvertinimas buvo geras ar ne. Taigi ar galime kaltinti žmones, jog jiems sunkiai sekasi daryti tai ko jie niekada nedarė?

Baimė suklysti

Antroji priežastis yra visiems gerai pažįstama baimė suklysti. Ypač, jeigu pagal pasakytus užduoties atlikimo vertinimus vėliau tas pats (o dar blogiau – kitas) darbuotojas yra matuojamas ar jis „gerai” dirba ar ne. Be abejo tada prasideda žaidimai su laiko vertinimais, kai darbuotojas padaugina planuojamą laiką iš mistinio koeficiento (pvz. PI), nes žino, jog po to vadovas tą laiką padalins bent jau iš dviejų, tik tam, kad sutilpti į projekto planą. Argi nebūtų geriau jei tiesiog visi atvirai diskutuotų kokia užduotis kiek laiko iš tikrųjų galėtų užimti? Kad visi suprastų, jog čia tik planas, ir realus jos įgyvendinimo laikas tikrai skirsis. Tiesiog skirtumas bus protingos paklaidos ribose.

Neteisingas klausimas

Dažniausiai girdimas projektų vadovų klausimas yra “kiek laiko užtruks atlikti užduotį?”.  O jeigu jūsų paklaustų, kiek laiko užtruks jums nuvykti tarkim iš Vilniaus į Kauną? Kokį atsakymą pateiktumėt tokiai labai aiškiai užduočiai? O jei vėliau sužinotumėt, jog reikės užsukti dar ir į Elektrėnus kažko paimti? Išvažiuoti ne vidury dienos, o piko metu? Ir iš Saulėtekio (kita Vilniaus pusė važiuojant į Kauną)? Taigi ar tikrai gali darbuotojas atsakyti į šį klausimą teisingai, kai dažniausiai jis negali įtakoti kitų veiksnių: prie kelių projektų dirbs tom dienom, kiek bus trukdomas, kaip aiškiai bus aprašytos detalės ir pan.

Kaip manote kas yra atsakingas dėl visų šitų priežasčių atsiradimo? Gal mes, vadovai? Gal reikalaujame kažko, kas nėra sąžininga darbuotojų atžvilgiu? Kitame straipsnyje pasidalinsiu, ką aš stengiausi daryti, kad šias priežastis pašalinti.

Neabejoju, jog nenorui vertinti užduotis pas jus buvo ir daugiau priežasčių. Pasidalinkit jomis komentaruose.

Tagged with: ,
Posted in Agile, Komanda, Scrum, Užduočių vertinimas
7 comments on “KODĖL sunku vertinti užduočių atlikimo laiką?
  1. Tiksliai ir į temą Tomai! 🙂

  2. Paulius says:

    Gera Tomo nuoroda 🙂

    Tikslų estimate’ą galėtume pasiekti lygindami užduočių kompleksiškumą su anksčiau buvusiomis, tačiau kyla klausimas – ką daryti, kai užduotys skiriasi iš esmės, ir nėra su kuo palyginti, ypač kai reikia skirti laiko analizei (investigation), pvz.: užduotis “Optimizuoti paiešką, kad ieškotų greitai ir rezultatai būtų tikslūs”. Aišku, galima daryti atskiras užduotis – analizei ir vykdymui, bet vykdymo estimate’as bus aiškus tik po analizės. Tokiu atveju, užduotis būtų pilnai įgyvendinta tik kitoje iteracijoje (scrum atveju), o poreikis gali turėti funkcionalumą greičiau.

    Kitas atvejis – kai dirbama prie skirtingų projektų ir jiems ta pati užduotis gali trukti labai skirtingą laiką – dėl techninių niuansų, dėl seno ir problematiško kodo ir pan.

    Dar viena situacija – vertinant užduotį yra tiksliai nežinomi tam tikri niuansai, kurie išryškėja jau pradėjus daryti užduotį. Tai gali būti tiek techniniai niuansai, tiek funkciniai. Dėl to pradinis estimate’as tokiais atvejais yra viršijamas.

    Nors kartais vertinant užduotis kyla noras “padauginti estimate’ą iš mistinio koeficiento”, bet tada iškyla Parkinsono taisyklės situacija. Taip pat vertinant Sprint’o rezultatus atsiranda tikimybė, kad nebus pastebėtos galimos problemos.

    Mes turime laiko “buferį”, kurį naudojame užduotims, kurios atsiranda sprinto eigoje (tokių visada būna ~20-25%).
    Per sprinto retrospektyvą trumpai apžvelgiame šias užduotis bei užduotis, kurių estimate’as buvo viršytas ir stengiamės pašalinti problemas, kurios tai įtakoja.
    Žinoma, problemos būna iškeliamos ir dieninių susirinkimų metu, bet situacija “Užduotis užtruks ilgiau, nes …” nėra tas atvejis, kurį galima būtų išspręsti iškart (jei priežastis ir sprendimas yra aiškūs).

  3. Pauliau, paprovokuosiu dviem klausimais: kaip manai, ar tikrai būtina (ir naudinga projektui) turėti tikslų kiekvienos užduoties vertinimą? Ar būna užduočių, kurios įvykdomos greičiau nei tikėtasi (jei taip, tai ar jas analizuojate kaip ir vėluojančias)?

  4. O tiems kas skaito Facebook, gali sekti gan įdomią straipsnio diskusiją ir ten: http://www.facebook.com/vaidas.adomauskas/posts/332251036814770?notif_t=share_comment

  5. Paulius says:

    Vaidai, mano nuomone, projektui tikrai naudinga turėti užduočių vertinimą apskritai. Kiek tikslus jis turi būti, jau tolerancijos klausimas, bet dažnai atsiremiama ir į ekonominius kriterijus (pvz.: ROI) ir nuo vertinimo gali priklausyti, ar užduotį reiktų daryti dabar, vėliau, ar apskritai nedaryti.
    Jei klystama labai stipriai, tie rodikliai išsikreipia ir iš padarytos užduoties gali nebūti jokios ekonominės naudos.
    Bet kokiu atveju, vertinimas ir tam tikra orientacija į laiką pristabdo galimą užduoties „išsipūtimą“. Tačiau negalima orientuotis vien tik į laiką, nes tada bijant viršyti planuotą laiką imama taupyti kokybės sąskaita. Tai dažnai nutinka, kai viršijamas planuotas laikas yra traktuojamas kaip asmeninė problema (tipo “nespėjai padaryt, vadinasi lėtai, t.y. blogai dirbi”), nors būna ir tokių atvejų…

    Dėl greičiau padaromų užduočių nei planuota, taip, būna, tačiau vertinimo skirtumai nebūna tokie kardinalūs. Dažniausiai laikas „sutaupomas“, pvz.: panaudojus technologiją B vietoj planuotos A. Tokiu „atradimu“ dažniausiai pasidalinama sprinto eigoje, nelaukiant retrospektyvos, tad papildomos analizės nedarome.

  6. Aš be abejo pritariu, jog projektas privalo turėti kaštų paskaičiavimą ekonominiam naudingumui nustatyti. Tačiau aš nesu įsitikinęs ar tam pasiekti reikia turėti kiekvienos užduoties tikslų įvertinimą. Jei mes turime 2 mėn projektą, ar svarbu jog procedūros atnaujinti kliento duomenis sukūrimas užtruks 6 ar 8 valandas? Ką aš noriu pasakyti, kad netgi įsivertinus visas detalias užduotis kaip įmanoma tiksliau, jų laiko suma niekada nebus lygi projekto atlikimo laikui. Todėl siūlau atskirti projekto funkcijų dydžių vertinimą ROI/ekonominio naudingumo paskaičiavimui (ir vertinti tai pvz istorijų taškais, vėliau tiesiog palyginant su panašaus dydžio projektų kaina), ir smulkių užduočių vertinimą kasdieniam darbui (dažniausiai vertinamą valandomis). Labai dažnai mano nuomone šitas sudedama į vieną tikintis, kad po to užteks susumuoti valandas. Deja, čia matematika neveikia.

    Visiškai pritariu jog laikas pristabdo galimą užduoties išsipūtimą. Todėl tavo pavyzdyje pateiktą užduotį “Optimizuoti paiešką, kad ieškotų greitai ir rezultatai būtų tikslūs” aš vertinčiau taip: Pirmiausiai pagalvočiau kiek biznio vertės tai sukuria ir kiek galiu į tai investuoti. Tarkim 5 darbo dienas. Ir tada duočiau komandai užduotį suformuluotą taip: “Per 5 dienas kiek galima maksimaliau optimizuoti paiešką, kad ieškotų greitai ir rezultatai būtų tikslūs”. Taip komanda turi limitą kuris pateisinamas išlaidomis, ir yra laisvi pasirinkti galimus techninius sprendimus. Kiek jie “suoptimizuos” iš anksto vis tiek neįmanoma pasakyti. Tad turėtų užtekti po 5 dienų pamatuoti optimizacijos rezultatus ir taip pamatuoti šios užduoties sėkmę. Jei yra noro, tikslą šių 5 dienų optimizacijos galima bandyti apsibrėžti ir iš anksto (pvz užklausa įvykdoma 2x greičiau), bet čia jau darbo su komanda detalės.

    Na ir tikrai siūlau daugiau laiko retrospektyvose skirti užduotims kurios įvykdytos greičiau/sėkmingiau analizuoti. Nustebsit kiek galima iš to pasimokyti, kad ir kitos užduotys lengviau eitųsi. Paprastai mes per dažnai analizuojame kas buvo blogai, ir labai retai susifokusuojame kaip užtikrinti, kad tai, kas buvo gerai, kuo dažniau kartotųsi. Pamėgink.

1 Pings/Trackbacks for "KODĖL sunku vertinti užduočių atlikimo laiką?"
  1. […] straipsnyje išvardinau mano manymu svarbiausias priežastis „KODĖL sunku vertinti užduočių atlikimo laiką?“. Šiame straipsnyje pasidalinsiu ką aš stengiausi daryti, kad šias priežastis […]

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Artimiausi mokymai
Data Mokymai - Lektorius
2017 m. rudenį Certified Scrum Master (CSM)
2017 m. rudenį Certified Scrum Product Owner (CSPO)
2017 m. rudenį Reikalavimų valdymas Agile projektuose - Vaidas Adomauskas
2017 m. rudenį Agile projektų valdymo pagrindai - Vaidas Adomauskas
2017 m. rudenį ICAgile sertifikuotas profesionalas (ICP) - Vaidas Adomauskas
Visi mokymai
Archives
Categories
Kontaktai

Viešos mokymų klasės:
E-paštas: mokymai (at) agilecoach.lt
Mob. tel.: 8 600 38860

Konsultacijos ir mokymai įmonėms:
E-paštas: vaidas (at) agilecoach.lt
Mob. tel.: 8 600 38860