Joseph LeDecoux omakorda koos oma kolleegida tõestas, et inimene võib emotsioone kogeda juba ennem kui on omale teadvustanud selle tegeliku allika. Nii võib inimene tunda hirmu juba ennem kui teadvustas, mida tegelikult nägi, näiteks madu või hiirt vms. Ehk teisisõnu kognitiivseid protsessid toimuvad alateadlikult ja alles lõpptulemus ise on teadvustatud.

Ehk seega ratsionaalne pool ei saa mingil moel toimida ilma emotsionaalseta.

http://tarkvara.tv/artiklid/tarkvaraarendus/toovotuleping-ja-kasundusleping/

Edasi aga on küsimus, kas tegemist on fikseeritud eelarvega või avatud eelarvega. Kumbki lepingu liik ei välista otseselt ükskõik kumba eelarvepoliitika kasutamist. Juhul kui tööga seonduvad instruktsioonid tulevad ikkagi töö enese käigus ehk protsessi, siis on sisuliselt tegu käsunduslepinguga.

Kurb tõsiasi aga on, et tellijad sageli püüavad sundida tellimuse täitjat võtma käsunduslepingu iseloomuga tööd töövõtulepinguga.

Küll pean siinkohal mainima, et standardit on lihtsam jälgida ja kasutada, kuna see on konkreetsem.

Suur roll on ka tarkvarakoodi kvaliteedi tagamisel ja võtmeroll korrektsel ning põhjalikul teistimisel ja testimisvigade parandamisel, mille pealt ei tohi kokku hoida!
Parem kallim tarkvara ja vähem funktsionaalsust, kui palju funktsionaalust ja vähe kasutustõhusust. See mõjutab konkreetselt töö tulemuslikkust ja sageli mitte vähe.

Meeles tuleb pidada, et tarkvaarenduses nagu mujalgi on osapooltele oluline töö tulemina saadud kasu. Seega tarkvarafirma eesmärk on olemasolevate ressursside raames minimeerida arenduskulud ja maksimeerida omanikutulud ning tellija eesmärk on maksimeerida arendaja arenduskulud ja minimeerida arendaja tulud.

Sellest tulenevalt soovib üks pool teha võimaluste piires võimalikult vähe ja teine pool saada võimaluste piires võimalikult palju. Mille tulemusena omakorda püütakse ühelt poolt kokku hoida projektijuhtimiselt, koodi kvaliteedilt, testimiselt ja kasutusmugavuselt ning teiselt poolt püütakse nõuda võimalikult palju funktsionaalsust ja mittefunktsionaalsete nõuete täitmist. Õige tee on osapoolte võimaluste ja soovide vahel, kokkuleppeline. Ühel poolel peab olema kasumit ja teisel poolel efektiivset tulemit.

Väärt postitus, aga kuidagi liialt suur tekstiblokk on ja peaks kindlasti olema paremini liigendatud.
Olen kirjutanud ka nende teemade kohta ühe postituse. Loodan, et on abiks
http://www.dreamgrow.ee/4776-perfekstse-blogipostituse-kirjutamine/

Muidugi ei oleks siis iga kasutaja jaoks üks ja sama “raamatukogutädi”, vaid ta oleks vastavalt inimese enda eelistustele kujundatud selliseks, kes sulle kõige rohkem antud olukorras sobib. Ehk siis see, mis mõnes ulmeraamatus on mainitud saab kunagi üsna tõenäoliselt tõeks.

Kirjutasin ka ise hiljuti ühe postituse kasutajakogemuse teemal: http://urgoringo.wordpress.com/2010/07/09/user-experience-and-aesthetics/

Näitena mõõdetavate tulemite kohta:
1. Efektiivsuse kasvu, mida saab mõõta näiteks ühele protsessile kuluva aja kaudu. Mõõdetakse seda enne ja pärast projekti etappi. ROI mõttes korrutatakse see tavaliselt sisemise tunnihinnaga läbi
2. Kliendirahulolu saab mõõta projekti lõpus läbi rahuloluküsitluse või teatud perioodis kliendile kordusmüükide arv
3. Vigade parandusele kulunud aeg protsentuaalselt projekti mahust
4. Ettepandud muudatuste hulk peale funktsionaalsuse arendust (protsentuaalselt projektimahust)
5. Projektimeeskonna tagasiside küsitlus (küsitluste kasutamine mõõdikutena ei ole alati objektiivne. Kui võimalik võiks siiski mõõta fakte, mitte arvamust)
6. Kasutatavust ja kasutaja protsessi pikkust on võimalik mõõta, kui tarkvara kvalitatiivse näitajana
7. Perioodis töölt lahkunud töötajate arv võib olla ka näiteks üks mõõdik
8. Kindlasti arendustöödest saadav kasum, mis on kogu protsessiparendamise majanduslik põhjus

Kõike ei ole mõtet ka korraga mõõta, sest kõiki näitajaid ei parendata ning osa näitajaid võib minna ka mõne teise eesmärgi saavutamise nimel kehvemaks. Mõõdikud tuleb vastavalt eesmärgile valida. Pea alati on võimalik edu/tagasiminekut mõõta (küll vahest läbi kaudsete näitajate).

Antud protsess ei ole nii tulemuslik, kui ettevõttes või arendustiimides on juba pöördumatud konfliktid. Protsess toimib, kui probleemid ei ole isikute tasandil vaid kokkulepete tasandil. Sõltuvalt sellest, kui palju on heitunud töötajaid on mõjutatud uuringute tulemus ning suuresti vürtsitatud isiklikest tugevatest emotsioonidega. Nii on võimalik teatud juhtudel (sõltuvalt uuringu läbiviija kogemustepagasist) tulemuseks saada vale hinnang probleemide tõsidusele. Tulemusena alustatakse vähem tähtsate probleemide lahendamisega, kust kasu nii palju ei tule.

Nagu igas konsultatsioonis ja muudatusi käsitlevas töös tuleb vältida ka konfliktide teket juurutus- ja uuringu protsessis. Olen näinud projekte, mis on selle pärast jäänud kesistele tulemustele või katkestatud. Muudatusi tuleb “müüa” läbi isikliku kasu.