Kolmas
Kolmanda mõtteavaldusena ei räägi ma Teile mingist konkreetsest ebaõnnestunud projektist, vaid oma juhumõtteid isiklikest kokkupuudetest sellega, nii positiivses kui negatiivses võtmes. Projektide nimesid avaldamata, mõelge ise, kas ja kuidas need võivad olla seotud projekti võimaliku ebaõnnetumisega
Koosolekud, nende pikkus ja osalejad.
Milline mõju võib olla projektile 8 tunnistel koosolekutel, kus osaleb kokku üle 30 inimese ? Arendaja poolt tavaliselt 3-5 inimest, ülejäänud Tellija poolt, tavaliselt keskastme juhid, osakondade juhatajad, aga ka projekti toetavad tehnilised inimesed, nii vähe kui neid vaja on. Selgitatakse lahenduse alustalasid ja alati keegi oskab küsida võib-olla õigustatud küsimusegi "Miks me seda teeme. Mis projekt see on ?" Heal juhul kulub vaid üle 1 päevaga korraga üle 240 tunni tööaega, rääkimata kaasnevatest kuludeks. Õnneks ei lähe see kõik projekti eelarvesse.
Koosoleku pikkus peaks olema limiteeritud, näiteks kahe tunniga, ja seal peaksid osalema vaid need isikud, kes on pädevad koosolekuteemat arutama, otsuseid vastu võtma ning on selleks koosolekuks valmistunud.
/Agiilne/ Metoodika.
Paljudes hangetes nõutakse juba agiilse metoodika kasutamist, (kuna sellisel juhul pidavat tulemused paremad olema ?). Arendaja üldjuhul kasutabki agiilset metoodikat, sest tema ressurss on projektis piiratud. Aga kas ka klient ? Endiselt veel tehakse mitmes riigiasutuses tellitavaid arendustöid "agiilselt", aga enamus auru kulub seal "koskmeetodil" arvestatud eelarverahade kokkuviimisel arenduse agiilsuse metoodikaga, millega Tellija raamatupidajad ei saa hakkama. Neid kääre ei õnnestugi tavaliselt kokku viia. "Meil on ju hankes nii kirjutatud, miks me seda nii /agiilselt/ teeme ?"
Agiilsuse mõtte sisu on paindlikkus, see peab puudutama kogu projektorganisatsiooni, mitte ainult arendaja oma.
Projekti skoop.
Hanke dokumentatsioon sisaldab tavaliselt Hanke/Objekti tehniline kirjeldus. Selles dokumendis võib olla kirjas kõik, mis asjaga kokkupuutunutel pähe tuleb, et jumala pärast midagi välja ei jääks. Selline dokument on arendajale paras pähkel, sest kuidas hinnata lauset "Rakendus peab olema integreeritud e-toimikuga", kui äri poole peal pole selleks selgitusi, aga arendustööde käigus, arenedes, suudetakse sinna "võluda" ikka 2-20 teenust. Kas need on skoobis ? ON, sest klient nõudis seda selles lauses. EI OLE, sest neid teenuseid pole tellitud. Ja nii hakataksegi skoobi üle vaidlema.
Isiklikult arvan, et mida lühemalt nõuded infosüsteemile kirja panna, seda odavam tuleb ka kliendile saada selline süsteem, mida ta ka tegelikult vajab. Kasutajate, nende tegevuste ning kasutatavate andmestike kaardistamine ei ole nii suur ja kallis töö, et seda mitte teha. Siit soovitus Tellijale : Keskenduge kõige olulisemale, siis saab selle ka tööle, püüdes kõike kirja panna ja iskamata seda siduda ja prioritiseerida, hägustub ka kogu skoop.
Järgmiste kohtumisteni
PS! Kui see mõtteavaldus kuidagi puudutas Teid või avardas Teie silmaringi, siis Avaja tänab ette tagasiside eest.
Avaja
Koosolekud, nende pikkus ja osalejad.
Milline mõju võib olla projektile 8 tunnistel koosolekutel, kus osaleb kokku üle 30 inimese ? Arendaja poolt tavaliselt 3-5 inimest, ülejäänud Tellija poolt, tavaliselt keskastme juhid, osakondade juhatajad, aga ka projekti toetavad tehnilised inimesed, nii vähe kui neid vaja on. Selgitatakse lahenduse alustalasid ja alati keegi oskab küsida võib-olla õigustatud küsimusegi "Miks me seda teeme. Mis projekt see on ?" Heal juhul kulub vaid üle 1 päevaga korraga üle 240 tunni tööaega, rääkimata kaasnevatest kuludeks. Õnneks ei lähe see kõik projekti eelarvesse.
Koosoleku pikkus peaks olema limiteeritud, näiteks kahe tunniga, ja seal peaksid osalema vaid need isikud, kes on pädevad koosolekuteemat arutama, otsuseid vastu võtma ning on selleks koosolekuks valmistunud.
/Agiilne/ Metoodika.
Paljudes hangetes nõutakse juba agiilse metoodika kasutamist, (kuna sellisel juhul pidavat tulemused paremad olema ?). Arendaja üldjuhul kasutabki agiilset metoodikat, sest tema ressurss on projektis piiratud. Aga kas ka klient ? Endiselt veel tehakse mitmes riigiasutuses tellitavaid arendustöid "agiilselt", aga enamus auru kulub seal "koskmeetodil" arvestatud eelarverahade kokkuviimisel arenduse agiilsuse metoodikaga, millega Tellija raamatupidajad ei saa hakkama. Neid kääre ei õnnestugi tavaliselt kokku viia. "Meil on ju hankes nii kirjutatud, miks me seda nii /agiilselt/ teeme ?"
Agiilsuse mõtte sisu on paindlikkus, see peab puudutama kogu projektorganisatsiooni, mitte ainult arendaja oma.
Projekti skoop.
Hanke dokumentatsioon sisaldab tavaliselt Hanke/Objekti tehniline kirjeldus. Selles dokumendis võib olla kirjas kõik, mis asjaga kokkupuutunutel pähe tuleb, et jumala pärast midagi välja ei jääks. Selline dokument on arendajale paras pähkel, sest kuidas hinnata lauset "Rakendus peab olema integreeritud e-toimikuga", kui äri poole peal pole selleks selgitusi, aga arendustööde käigus, arenedes, suudetakse sinna "võluda" ikka 2-20 teenust. Kas need on skoobis ? ON, sest klient nõudis seda selles lauses. EI OLE, sest neid teenuseid pole tellitud. Ja nii hakataksegi skoobi üle vaidlema.
Isiklikult arvan, et mida lühemalt nõuded infosüsteemile kirja panna, seda odavam tuleb ka kliendile saada selline süsteem, mida ta ka tegelikult vajab. Kasutajate, nende tegevuste ning kasutatavate andmestike kaardistamine ei ole nii suur ja kallis töö, et seda mitte teha. Siit soovitus Tellijale : Keskenduge kõige olulisemale, siis saab selle ka tööle, püüdes kõike kirja panna ja iskamata seda siduda ja prioritiseerida, hägustub ka kogu skoop.
Järgmiste kohtumisteni
PS! Kui see mõtteavaldus kuidagi puudutas Teid või avardas Teie silmaringi, siis Avaja tänab ette tagasiside eest.
Avaja
Comments
Post a Comment