Targo tarkvara

Sellekevadine Tartu Ülikooli projektijuhtimise kursuse epopöa on vähemalt minu jaoks selleks korraks otsa saanud ja kõik eksamitööd parandatud.

Kokkuvõttena torkavad üliõpilaste töödes silma mitmed ühised jooned, millest mõned, kui neid päris elus rakendada, rohkem või vähem eepiliste projektifeilidega lõppeks (neil, kes korralikult loengus käisid, läheb muidugi paremini )

Eksamil tuli kirjutada järgmist (kõik punktid olid enne teada):

• Mingi tarkvaraprojekti kirjeldus
• Projekti etapid
• Projekti tehnoloogilised osad
• Projekti kalkulatsioonid
• Meeskonnamudel
• Ja lõpuks üks suur tabel kirjeldamaks, kes, mida ja miks projekti vältel teeb.

Esimese asjana jäi paljudele segaseks, millised kulud ühe projekti või ettevõtte juhtimisega kaasnevad. See tähelepanek ei ole isegi mitte tarkvaraspetsiifiline, aga rakenduks ka suvalisele muule projektile.

Erilist äramärkimist vajab siin see, et paljud ei tea, millised on tegelikult Eesti maksud. Mitmed tulid tulu-, aga mitte sotsiaalmaksu peale, mitmed eeldasid aga lihtsalt, et projekt täpselt nii palju maksabki, kui palju raha nemad koju viivad. Oleks elu vaid nii lihtne

Loengus oli toodud arvutus, mille järgi kujuneb programmeerimistöö tunnihind järgmistest komponentidest:

• Tehniliste töötajate netopalk.
• Tulu-, töötuskindlustuse ja sotsiaalmaks - Eesti ettevõtete tegelik palgakulu oli kuni viimase ajani 1,71*netopalk, aga maksud kipuvad viimasel ajal ebastabiilsed olema.
• Kontorikulud. Siia alla kuuluvad suurima kuluna mittetehniliste töötajate (juhtkond, raamatupidamine, müügipersonal, IT tugi, ilus tüdruk ees lauas jne jne) palgakulud ja teiseks üür, elekter, riistvara amortisatsioon jne. Kontorikulud kõiguvad ettevõttest ettevõttesse muidugi suuresti, aga võiks arvestada viiekohalise summaga iga tehnilise töötaja kohta kuus.
• Puhkuste ja haigepäevade tasu, kus väärtust ei toodeta, aga palgakulu jookseb edasi.
• Tööaja sisene ebaefektiivsus. Kui mingi asi võtab 10 tundi programmeerimist, siis ei tähenda see sugugi mitte kümmet tööl istutavat tundi. 70% efektiivsus on enamasti super tulemus, enamik organisatsioone jääb oluliselt alla selle.
• Ettevõtte kasumimarginaal.

Konkreetsed arvud võib igaüks siia nüüd ise asendada ja kokku korrutada – tulemuseks on nii mõnegi inimese jaoks ehmatamapanevalt suured käärid. Nende asjaolude mittearvessevõtmine oleks päris elus nii mõnegi särasilmse firma pankrotti viinud.

Teiseks, kui midagi kirjutad, siis tunne oma lugejaskonda.

Mitte ilmaasjata ei tulnud küsimustes projekti struktuuri mitu korda kirjeldada:

• Üks neist vaadetest on kliendile (kes tahab lihtsalt lühidalt ja konkreetselt teada, mida ja mis ajaks ta saab)
• Teine on juhtivale tehnilisele personalile (kes tahab teada, milliseid metoodikaid ja tehnoloogiaid me kasutame)
• Kolmas on projekti igapäevastele osalistele (kes tahavad teada, mida mingil päeval plaanitakse teha)

Ja last but not least, tuleb arvestada õppejõuga, kes selle kõik läbi vaatab, et kas inimene on kursusest ka midagi kõrva taha pannud või imes kogu jutu lihtsalt pastakast välja

Paljudes töödes oli näha suhtumist: mina olen vinge programmeerija, progemine on ainus asi, mis loeb, tean kõike kõige paremini ja ei pea teistele midagi selgitama. Bzzzt, selline suhtumine seab inimese karjäärile üldjuhul olulise tõkke, rääkimata olukordadest, kus projekt hävib seetõttu, et kliendile jäid asjad segaseks.

Ja lõpuks: sõbrad, õppige kirjutama.

• Ärge kirjutage poole lehekülje pikkusi lõike, neid ei viitsi ükski klient lugeda.
• Vaadake, et professionaalne tekst annaks edasi võimalikult palju konkreetseid detaile.
• Kasutage teksti ilmestamiseks jooniseid või kasvõi bullet pointe, et oleks võimalik ühe pilguga haarata, millest jutt käib.

Ja korrektne on kirjutada standardne, kontseptsioon, stsenaarium ja mõttetu, vastasel korral arvab iga haritum klient, et te olete lohakad ja kirjutate koodi ka üle jala.

Kokkuvõttes oli tegemist aga vähemalt minu enda jaoks hinnalise kogemusega, loodetavasti said ka kuulajad oma filosoofilisele potentsiaalile lisa. Ülaltoodud kaebustest hoolimata olid mitmed tööd täitsa head ja nende autorid (te teate, kes te olete ) võtan ma vajadusel kindlasti oma kampa.

Majandusteadusliku definitsiooni järgi on rahal kolm peamist rolli:

• Vahetusvahend (et me ei peaks oma tarkvara otse ülikondade ja pirukate vastu vahetama)
• Arveldusühik ehk väärtuse mõõt (et me saaks aimu, mitu pirukat meie tarkvara väärt on)
• Akumulatsioonivahend (pirukaid ja Windows Vista karpe teatavasti tagavaraks ei kogu)

Igapäevasuhtlemises on rahal aga tihti kehv aura, raha seostatakse peamiselt asjade, kulutamise ning tarbijalikkusega.

Ma ise olen eluaeg vilets tarbija olnud, aga raha meeldib mulle sellegipoolest. Täpsemalt meeldib mulle idee raha teenimisest kui väärtuse loomisest.

Konkreetselt tarkvara kontekstis: vaba vs kommertstarkvara on väga poleemiline teema, mille üle vaieldakse hääli kähedaks ja kulutatakse klaviatuure auklikuks. On inimesi, kelle arvates tarkvara eest raha küsimine on võrreldav kutsikate piinamise ja muude koledustega. On inimesi, kes teevad tarkvara lihtsalt sellepärast, et neile meeldib tehnoloogia ja asjade kallal nikerdamine. Kas sellest tarkvarast ka kellelegi kasu on, pole nende jaoks nii väga oluline, nad saavad oma rahulduse lihtsalt asjaga tegelemisest.

Samas, kui ma teen valmis mingi tarkvaratüki ja selle eest raha saan, tähendab see, et ma olen maailmale lisanud konkreetselt selle rahahulga eest lisaväärtust, sest kellegi arvates oli tegemist piisavalt hea asjaga, et selle eest maksta. Mida rohkem makstakse, seda suurem on kliendi silmis minu tarkvara väärtus ja seda rohkem olen ma asjaga rahul.

Seega, mõtteviisis, mille järgi me tahame oma tarkvara eest võimalikult palju raha saada, pole midagi halba ega koledat, sest see sunnib meid pidevalt mõtlema, kuidas oma tarkvara kasutaja jaoks võimalikult väärtuslikuks teha. Ainult tehnoloogilisele aspektile keskendumine tekitab situatsiooni, kus programmeerija meelest on tegemist millegi ülivingega, aga kasutaja kehitab sellegipoolest õlgu, sest konkreetselt tema mugavuse peale pole keegi mõelnud.