Projekto tvarkaraštis ir jo sekimas


Projekto tvarkarascio pavyzdys. Optinistiniai veiksmazodziai.

Informatikos referatas. Įvadas. Pagrindinės vėlavimo priežastys. Komentarai apie “vėlavimą”. Pagrindiniai tvarkaraščio sudarymo principai. Ryšiai tarp žmonių ir pastangų. Pavyzdys. Empiriniai ryšiai. Pastangų paskirstymas. Projekto užduočių nustatymas. Griežtumo laipsnis. Adaptavimo kriterijaus apibrėžimas. Užduočių paketo parinkėjo reikšmės skaičiavimas. Tss reikšmės interpretavimas ir užduočių paketo parinkimas. Programų sistemos inžinerijos užduočių parinkimas. Bazinių užduočių tikslinimas. Užduočių tinklo nustatymas. Tvarkaraščio sudarymas. Laiko juostos diagramos. Tvarkaraščio sekimas. Projekto planas. Santrauka. Klausimai.


Vėlais 1960-ais vienas inžinierius buvo parinktas rašyti kompiuterines programas. Jis buvo parinktas todėl, kad buvo vienintelis iš tos grupės, kuris lankė kompiuterinio programavimo kursus. Jis gerai išmanė asemblerio ir fortran kalbas, bet nieko neišmanė apie programų sistemų inžineriją ir juo labiau apie projekto tvarkaraščius. Jo bosas įteikė aprašymą ir žodžiu paaiškino, ką reikia jam padaryti, be to pranešė, kad darbas turi būti baigtas per du mėnesius.

Po savaičių jį pasikvietė bosas ir paklausė kaip sekasi dirbti. Jaunas inžinierius atsakė, kad sekasi puikiai, kad darbas pasirodė esąs daug lengvesnis nei jis galvojo ir kad jis padarė jau apie 75% viso darbo.

Dar po savaitės bosas pasikvietė inžinierių vėl ir paklausė, kurioje stadijoje yra darbas. Jaunuolis atsakė, kad susidūrė su keliomis smulkiomis kliūtimis, bet greitai jas išspręs, ir kad jau beveik 90% darbo atlikta.

Jeigu jūs dirbate kompiuterinių programų kūrimo srityje, tai lengvai galėtumėte pabaigti šią istoriją. Žinoma jaunas inžinierius ilgai dar buvo padaręs tik tuos 90% darbo. O visas darbas buvo pabaigtas (žinoma su kolegų pagalba) mėnesiu vėliau negu buvo numatyta iš anksto.

ši istorija dar tūkstančius kartų būdavo kartojama programuotojų per nerealus galutinis terminas (deadline) nustatytas kažkieno iš išorės ar vadovų programuotojų/projektuotojų (software engineering) grprojekto valdymo trūkumai, kurie trukdo vadovui ar kitam asmeniui laiku pastebėti atsilikimą nuo tvarkaraščio. Taip pat, kai yra imamasi per mažai veiksmų tam atsilikimui panaikinti.

Agresyvūs (ir nerealūs) galutiniai terminai (deadline) yra realybė verslo pasaulyje. Dažnai tokie galutiniai terminai yra pagrįsti, žiūrint iš žmogaus, kuris tuos terminus nustato, pozicijos, bet sveikas protas sako, kad tokie terminai turėtų būti suprnapoleonas kartą pasakė: kiekvienas karvedys, kuris įsipareigojo įvykdyti planą, kuris turi trūkumų ir klaidų, turi sutelkti jėgas priežasčių (trūkumų ir klaidų) išsiaiškinimui, reikalauti, kad planas būtų pakeistas, ir netgi turi atsistatydinti, kad netaptų savo armijos pralaimėjimo įrankiu . Čia žodžiai, kuriais turėtų vadovautis kiekvienas projekto vadovas.

Rizikos įvertinimas ir tvarkaraščių sudarymas dažnai vykdomi jau nustačius galutinį terminą (deadline). Jei optinistiniai įvertinimai parodo, kad galutinis terminas yra nerealus, tai projekto vadovas turėtų apsaugoti savo komandą nuo blogo tvarkaraščio spaudimo ir pats turėtų pradėti spausti tokių terminų autorius.

  • Informatika Referatai
  • 2010 m.
  • 20 puslapių (6384 žodžiai)
  • Informatikos referatai
  • Microsoft Word 48 KB
  • Projekto tvarkaraštis ir jo sekimas
    10 - 2 balsai (-ų)
Projekto tvarkaraštis ir jo sekimas. (2010 m. Kovo 03 d.). http://www.mokslobaze.lt/projekto-tvarkarastis-ir-jo-sekimas.html Peržiūrėta 2016 m. Gruodžio 08 d. 11:57