Žudantis optimizmas, arba kodėl visi darbai užtrunka ilgiau

Yra toks kažkiek šmaikštus IT prietaras: jeigu kaip projekto vadovas ar užsakovas norite sužinoti, per kiek laiko programuotojas gali atlikti tam tikrą darbą, tai paklauskite jo paties ir jo atsakymą padauginkite bent iš dviejų, tada gausite realų laiką. Kadangi tenka pabuvoti abiejose barikadų pusėse – ir vadovo, ir programuotojo – tai galiu pasakyti, kad daugeliu atveju tai gryna tiesa. Tai ar programuotojai melagiai? Ne, taip nėra. Pabandykime panagrinėti situaciją.

Šią temą sąlygoja pastaruoju metu beprotiškas mano užimtumas su dviem projektais, kur viename iš jų esu vadovas, kitame – programuotojas. Pirmu atveju turiu tiesioginių įsipareigojimų prieš klientus, o pastaruoju atveju esu pavaldus projekto vadovei. Ir kai mane paskyrė kaip programuotoją į tą antrą projektą, manęs tiesiai paklausė, per kiek daugmaž laiko realizuosiu savo modulį. Viskas atrodė pakankamai nesudėtinga iš pirmo žvilgsnio, ir nurodžiau poros mėnesių terminą. Turėjau dar išmokti porą naujų technologijų, bet vėlgi pamaniau, kad mano programavimo patirtis pakankamai didelė ir problemų nebus. Sutarėme, kad po to modulio užbaigimo grįšiu pilnai prie mano webinio projekto vadovavimo.

Ir tada po truputį prasidėjo:

1. Pasirodė, kad to mano programuojamo modulio pagrindas yra kito programuotojo sukurtos bazinės klasės, kurios neturi praktiškai jokios dokumentacijos išskyrus gyvą paaiškinimą

2. Darbus skirstė ne vienas žmogus, o trys žmonės, kurie dažnai tarpusavyje nesutardavo, dėl to teko kai kurias funkcijas perdaryti

3. Dėl savo optimizmo ir kolegų dokumentavimo stokos programiškai „nugrybavau“ visai ne ten, kur reikia, dėl ko irgi kai kurias formas ir funkcijas teko perkurti nuo nulio

4. Iš vadovių, skirstančių darbus, vis dažniau girdėdavau žodžius „oi pamiršau, o dar reikia to, ir vėliau reikės ano…“ – darbų planas buvo kuriamas ir pildomas mano akyse

5. Galiausiai prasidėjo problemos su mano vadovaujamu webiniu projektu – turėjau kasdien skirti daug laiko vadovavimui, darbų skirstymui, kartais net programavimui, dėl to automatiškai darbo valandos ilgėjo.

Viso to pasekoje – prie to modulio jau sėdžiu daugiau negu pusę metų, retkarčiais prisėsdamas prie webinio projekto reikalų. Kita neigiama pasekmė – užleidau tinklaraštį, nes grįžtant po darbo tiesiog nebėra jėgų rašyti kažką rimto, o bet ko rašyti nesinori. Bet čia buvo laikina – jau nuo šiandien grįžtu į energingą rašymą. Bet užteks apie mane asmeniškai, iš mano konkretaus atvejo pabandykime išskirti priežastis, kodėl beveik bet koks darbas užtrunka iki galo daug ilgiau, negu tikimasi pradžioje.

1. Krūva iš anksto neapgalvotų faktorių ir aplinkybių

Mano konkrečius trikdžius išvardinau kiek auksčiau. Bet bendrai tų trikdžių gali būti labai įvairių: kolegų nesugebėjimas pagelbėti, prasti darbo įrankiai, netikėtai pasirodęs buvęs klientas su pageidavimais, sveikatos sutrikimai, egzaminų sesija – šį sąrašą galima tęsti ilgai. Ir čia ne dėl to, kad programuotojas tingi dirbti, visa tai išoriniai trikdžiai, kuriuos sunku iš anksto apskaičiuoti.

2. Perdėtas optimizmas

Iš praktikos sakau – beveik visi programuotojai yra perdėti optimistai. Daug kas, pažiūrėjęs į užduotį, turi iliuziją, kad viskas yra padaroma per dieną, o galvoje jau praktiškai iš karto gimsta programinis kodas. Ir kas įdomiausia, pirmas programos kodo „gabalas“ dažniausiai taip ir sukuriamas – ant smūgio, keliais prisėdimais. Tačiau vėliau prasideda…

3. Kompetencijos ir žinių stoka

Banali priežastis. Bet net ir labai patyręs programuotojas turi silpnų vietų savo srityje ir dažnai užsuka į forumus ar klausia kolegų patarimų ar nuomonės. O jei mažiau patyręs žmogus imasi naujos funkcijos, tai be pagalbos „iš viršaus“ gali gautis fiasko. Taip kad projekto įgyvendinimo laiką reikia matuoti pagal savo realias žinias, o ne pagal mintį „pakeliui išmoksiu, čia bus lengva“.

Tai tiek minčių šia tema, nors iš tikrųjų galima būtų dar plėstis pakankamai ilgai. Bet geriau užduosiu klausimą jums – ar neteko kada nusvilti nuo to paties blogio – perdėto optimizmo? Ar teko atsiprašinėti vadovų arba klientų dėl laiku nepadaromo funkcionalumo? Kaip sukotės iš padėties? Dirbote naktimis? Ir ar nepalūždavote kažkiek psichologiškai? Pasidalinkite patirtimi, gal ir man pačiam kažkiek palengvės 



       
Norite gauti Skaitykit.lt naujienas operatyviau? Prenumeruokite RSS įrašus
Jei nežinote, kas yra RSS ir kaip juo naudotis, apie tai galima pasiskaityti šiame puslapyje.

Komentarai

Komentarų: 6 prie straipsnio “Žudantis optimizmas, arba kodėl visi darbai užtrunka ilgiau”

  1. Pranas
    Vasaris 9th, 2010 12:13 pm

    >pirmas programos kodo „gabalas“ dažniausiai taip ir sukuriamas – ant smūgio, keliais prisėdimais. Tačiau vėliau prasideda…

    Čia galioja Pareto principas: 80% darbo užtenka 20% laiko, tačiau likusiems 20% darbo reikia skirti net 80% laiko :)

  2. oplia
    Vasaris 9th, 2010 2:00 pm

    Aš patarčiau:
    1.Sutramdyti “nora” nudžiuginti klientą kad užbaiksite greitai.
    2.Isiaiškinti iki kada darbas turi būti baiktas, arba kiek maždauk laiko gali būti skirtą jūsų darbo gabalui.
    3.Išsiderėti daugiau laiko nei jums skiriama.

    Iš savo patirties.. :)

  3. IT naujienos
    Vasaris 9th, 2010 8:31 pm

    Reikia sakyti realų laiką. Jei baigsite anksčiau, pradžiuginsite klientą. Bet jei pasakysite minimalų terminą, kurio neįvykdysite, prasidės priekaištai.

  4. Karvė
    Vasaris 10th, 2010 1:39 am

    Reikia turėti procesą - projektas pradedamas nuo specifikacijos, kiekviena funkcija yra iš anksto apgalvojama produkto vadovo, kuris pasirūpina usability ir kitais klausimais. Visos formos jau aptartos ir aprašytos. Tada ir dirbti lengviau!

  5. Ričardas Š.
    Vasaris 15th, 2010 10:35 am

    Iš esmės nusakymas, kiek laiko užtruks projekto kūrimas, mano nuomone, priklauso nuo programuotojo patirties. Tik kurdamas daugybę projektų galų gale pradedi jausti, kiek tas ar anas laiko užtruks. Dėl šių priežasčių sunkiausia nurodyti galutinę datą mažiau patyrusiems ar tik pradedantiesiems.

    Žinoma, visada prisideda ir klientai, kuriems pateikus vienas prie vieno atitinkančią svetainę tokią, kokios norėjo, jie prisimąsto papildomų funkcijų arba persigalvoja dėl kitų. :)

    Čia nuo šios problemos neįmanoma pabėgti, nebent turima senų vilkų, puikiai tarpusavyje sutariančių komanda, kurios našumas priklauso tik nuo paties kliento.

  6. To Karve
    Kovas 4th, 2010 3:52 pm

    Specifikacija yra planavimo faze, tuo tarpu projektas visada pradedamas nuo iniciavimo fazes, t.y nuo project charterio.

Parašykite komentarą





Turinio valdymas: WordPress