•
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
•
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 »
•
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 »