•
Pāršķirstot vecus pierakstus atradu interesantu materiālu, kurā tika veikta komunikāciju iedalījums pēc to tipa: formāla, neformāla un rakstiska vai mutiska.
Pati par sevi šī tabula neko neizsaka, bet var kalpot kā labs uzskates līdzeklis. Iespējams kādam noderēs.
|
Formālā |
Neformālā |
| Mutiski |
Sapulce
Prezentācija |
Pīpētava
Kafijas pauze
Pusdienas
1:1 (viens pret viens) |
| Rakstiski |
Vēstules
Iesniegums
Rīkojums |
e-pasts
Skype
Čats |
No uzskaitītām efektīvākās skaitās:
Sapulces un neformālās 1:1 pārrunas
Visneefektīvākā skaitās e-pasts sarakste
•
Mūžīgais jautājums-
Kāpēc pasūtījumos bieži tiek noteikts:
soda nauda par termiņu kavējumu 0,1% par katru dienu, bet ne vairāk kā 10% no kopējā projekta summas?
Ar šādiem noteikumiem izstrādātājs var rēķināties ar 10% zaudējumu (sākumā palielina projektu summu par 10% un neko nezaudē 
) un vispār neiespringst nedz uz kvalitāti, nedz termiņiem.
Un pēc tam amatpersonas cēli paziņo, ka mēs neko nevaram darīt (nevaram iespaidot vai ietekmēt izstrādātāju), jo redz iespējamā soda procentu summa jau ir izsmelta! Pamāj ar galvu un apsola nākotnē kļūdu novērst, bet nākošo līgumu noslēdz tieši tādu pašu? Kad tas beigsies?!
Ps. Ko es ar to gribēju pateikt? Nepieļaujiet tādas kļūdas..
•
Nesen bija tas gods izpildīt testu, pēc kura vienā uzņēmumā tiek vērtētas IT administratoru zināšanas.
Man šis tests bija interesants divu iemeslu dēļ:
- Gribēju paskatīties pēc kāda principa citās iestādes tiek testētas zināšanas;
- Uzzināt savu rezultātu, jo 1,5 gadus neesmu neko administrējis.
Ja kādam gribas sevi pārbaudīt pēc “subjektīva zināšanu testa”, tad lūdzu. Protams, katram būs savs vērtējums vai ar šādu testu ir iespējams pārliecināties par admina spējām, bet tas tā… Talak »
•
Manas piezīmes par tēmu “zivs pūst no galvas”.
Daudziem ir zināma drūmā statika par to cik procentuāli daudz projektu izgāžas, neizdodas vai vienkārši nesasniedz savu sākotnējo mērķi.
Savā pieredzē arī esmu saskāries ar neveiksmīgiem projektiem, kurus vienoja divas būtiskas lietas.
Ps. Šeit nepieskaršos projektu vadīšanas procesam , jo tas ir atkarīgs no konkrētā projekta tipa, lieluma, utt.
Bet ir viena kopēja lieta- Projekta mērķis. Talak »
•
Vienu dienu izveidojās diskusija par indikatoriem, kas norādītu uz iespējamo krāpniecību uzņēmumā.
Kā viens no interesantākajiem man šķita ilglaicīgi neizņemts atvaļinājums, jo pats parasti turu rezervē vairākas atvaļinājuma dienas- ja nu pēkšņi ir nepieciešams kaut kur aizbraukt un tāpēc nesaskatīju tur neko nosodāmu. Talak »
•
Vienā sanāksē tika diskutēts, ko ir vērts pārbaudīt IT projekta ietvaros?
No visa iznāca divas galvenās atziņas:
- Ja auditors tiek iesaistīts projekta sākumā, tad var skatīties izmantoto metodoloģiju projektu vadībā un analizēt visu projektu vadības gaitu. Nepieciešamības gadījumā var norādīt uz vadīšanas vai plānošanas nepilnībām. Salīdzināšanai var izmantot angļu projektu vadības standartu PRINCE2(salīdzinot vai tiek izpildīti visi veiksmīga projekta priekšnosacījumi- Izpētīti ieguvumi, draudi, utt).
- Ja auditors tiek iesaistīts projekta beigās, tad vērtīgākais, ko var pārbaudīt un salīdzināt ir projekta sākumā definētos Busines-case ieguvumus ar reāliem, kas ir pēc projekta, tādā veidā pārbaudot vai projekts sasniedza tam izvirzītos mērķus. Otrs variants ir pārbaudīt nodefinēto prasību atbilstību izstrādātajai sistēmai, lai pārliecinātos, ka visas prasības ir izstrādātas.
Papildus tam projektu konsultēšanas laikā var palīdzēt izstrādāt dažādus kritērijus, pēc kuriem vadīties projekta laikā, tādā veidāatvieglot projektu vadītājam pieņemt lēmumu. Piemēram, kritēriji, kuriem jāizpildās, lai sistēmu varētu ieviest produkcijā(tai jābūt notestētai, veiktie stres testiem, drošības testiem, saņemta dokumentācija, utt) vai arī saņemtās lietotāju dokumentācijas kvalitātes un atbilstības analīze(to var salīdzināt pret LV standartu- LVS 66:1996), utt
Cits jautājums, vai šī analīze pēc tam tiek ņemta vērā..
•
Lasot projektu vadības standartu PRINCE2 uzgāju bildi, kurā ir nodalītas dzīves cikla sadaļas, kuras ir definētas kā produkta un kuras kā projekta daļas.
Nekā mega jauna jau nav, bet lasot atcerējos vecu strīdu ar bijušo kolēģi, par jautājumu vai sistēmas lietošana un uzlabošana ietilpst projektā vai arī izstrādes projekts beidzas ar lietošanas uzsākšanu.
•
IAI pagājušajā ikmēneša sapulcē tika diskutēts par IT auditiem un tipiskākajām problēmām IT projektos. Tādēļ, lai piefiksētu sev svarīgāko veicu apkopojumu, varbūt kādām noder. Prezentāciju vadīja Ēriks Dobelis.
Sākumā skaitļi- ap 84% IT projektu neiekļautās projekta sākumā nospraustajos termiņos un 56% neiekļaujas budžetā. Talak »
•
Iepriekšējais raksts: http://dll.lv/it-projektu-problemas-1/
2. Ieviešanas(izstrādes) problēmas
Galvenā problēma ir projekta plānošana, vadīšana un prasību definēšana.
Joprojām projekti tiek pasūtīti prasībās norādot vispārējas lietas, kuru realizācijas redzējums ļoti atšķiras starp pasūtītāju un izstrādātāju.
Biežāk izstrādē lietotās ir Agile un ūdenskrituma metodes.
Lielākā kļūda izstrādājot ir mēģināt apvienot abas izstrādes metodes un izgudrot kaut ko pa vidam, jo abās metodēs ir iestrādātas pilnīgi cita ideoloģija, kā rezultātā sistēma tiek izstrādāta pēc ūdenskrituma modeļa, bet ar nenodefinētu specifikāciju. Talak »
•
Meklējot nepieciešamās IT kompetences uzdūros interesantai lasāmvielai- ieteikumi administratoriem:)
Adminiem- Must know, jo ir daudzi, kuri par šīm dzīves īstenībām ir piemirsuši, līdz tām neaizdomājais vai vienkārši ignorē:
1. Nekad nedari to, ko nevarēsi pēc tam atjaunot iepriekšējā stāvoklī.
2. Vienmēr pārbaudi rezerves kopijas, nepaļauties tikai uz to esamību, bet pārliecināties, ka tiešām varēsi arī atjaunot.
3. Vienmēr pieraksti ko tu darīji, pat tad, kad uzskati, ka nekad to neaizmirsīsi.
4. Ja kaut ko dari vairāk kā vienu reizi, uzraksti skriptu, kas to darīs automātiski.
5. Iepazīsties ar lietotājiem pirms ir notikusi kāda problēma, jo kad tā notiks, viņi tevi jau pazīs un attieksies jau ar lielāku sapratni.
6. Atcerieks, ka nodrošini servisu lietotājiem, nevis esi sistēmas īpašnieks. Tu ar to darbojies, lai palīdzētu citiem.
7. Pārbaudi rezerves kopijas.
8. Nekad nepārtrauc mācīties, vienēr ir kaut kas jauuns, kas padarītu tavu sistēmu stabilāku, drošāku un tavu darbu vieglāku.
9. Atkal pārbaudi rezerves kopijas.
Sen sen atpakaļ viens draugs teica, sū… ar visu, ka tikai ir uztaisīts un pieejams backup Principā zelta vārdi…