English

RoBloggersSurvey2008

marker  Blog/Categorii
marker  Arhiva
marker  Calendar
  • August 2020
    Mon Tue Wed Thu Fri Sat Sun
    <<  <   >  >>
              1 2
    3 4 5 6 7 8 9
    10 11 12 13 14 15 16
    17 18 19 20 21 22 23
    24 25 26 27 28 29 30
    31
marker  Cautare
marker  Ultimele comentarii

Rezultate RoBloggersSurvey2007

TPark - sistem de parcare prin mobil

eLiberatica - The Benefits of Open and Free Technologies Conference 2008

Proiectul  Zestre pentru Europa  Capsula Timpului

eLearningBlog este blogul lunii august la jurnalismonline.ro

Castigator la categoria Cel mai informativ blog
marker Pe bloguri despre bloguri

Juriu roblogfest 2008

JobShop Timisoara

ProiectMPS

Comentare resurse
03/01/10

Buna,

Va rog ca mai jos, fiecare sa comenteze in cate 2-3 fraze 2 resurse gasite interesante dintre cele de la pagina sau altele pe tema managementul proiectelor.

Termen: saptamana 3.

Multumesc,
Carmen Holotescu

Posted by Carmen at 08:25:25 am into the following categories: Anunturi


Trackback address for this post:
http://www.timsoft.ro/weblog/htsrv/trackback.php?tb_id=1175

Comments, Trackbacks, Pingbacks:


Comment:

Yey, sunt prima!
Citind articolul celor de la SoftwareProjects.Org am ajuns la niste mituri de management software pe Scribd.com.
Consider ca aceste resurse plus cursul in sine ne vor fi folositoare atat pentru proiectul de licenta cat si in cariera.
Insa, cred ca imaginea urmatoare (o replica dupa cea din documentul de pe scribd.com .. nu am gasit originalul) cam explica diferitele viziuni ale unui proiect ... am patit-o si eu cu profesorul meu de licenta :P
http://www.hello.nl/photos2/software_engineering_explained.gif
Concluzie? Trebuie sa invat sa ma exprim mai bine!
O seara placuta!
Ioana

Posted by: Ioana Csiri [Visitor] on 03/03/10 @ 22:58
Comment:

Vad ca linkul la documentul de scribd.com nu e valid ... pentru cei interesati intrati aici -> http://www.scribd.com/doc/26402206/Software-Myths-Software-Project-Management
O seara placuta!
Ioana

Posted by: Ioana Csiri [Visitor] on 03/03/10 @ 23:00
http://stuffsipapura.blogspot.com/
Comment:

Multumesc pentru comentarii si spargerea ghetii, Ioana.

O seara placuta,
Carmen H

Posted by: Carmen [Member] on 03/03/10 @ 23:09
http://www.timsoft.ro
Comment:

Salut,

Foarte sugestive imaginile din URL-ul Ioanei. Mi-au placut mult. E clar ca specificatiile suna cat mai complicat, implementarea, ca de obicei scartaie, si de multe ori clientul nu primeste ceea ce dorea.

Oricum, am si eu doua chestii de spus. Una nu e legata de niciun link de pe site, e din propria mea experienta. Am facut practica la o firma care foloseste Silverlight in mare parte pentru proiectele lor. Si tin minte ca directorul firmei ne-a intrebat la interviul pentru practica cati vor sa isi faca o firma cand termina facultatea. Si spre surprinderea lui, nimeni nu a ridicat mana. El a fost oarecum dezamagit, vazand ca toti vrem sa ne angajam la o firma mare, unde sa fim veriga cea mai slaba si ca nu avem incredere in fortele noastre proprii. El a fost un exemplu ca se poate orice, atata timp cat iti doresti. Si din experienta lui, e greu, foarte greu la inceput dar nimeni nu s-a nascut invatat si nu trebuie sa fii un geniu pentru asta. Trebuie in orice caz sa ai si sa stii sa iti folosesti calitatile de manager, pentru ca la urma urmei, tu raspunzi de reusita sau esecul unui proiect.

Al doilea lucru, legat de unul din linkuri, Estimating and Metrics, parte care mie mi se pare grea si totodata interesanta. Software Metrics: Ten traps to avoid ne avertizeaza cu privire la ceea ce am invatat si azi, la curs. Este foarte important cand anume facem toate estimarile. Daca le facem inainte de orice, avem sanse de eroare de pana la 400%. Daca facem estimarile dupa ce cunoastem specificatiile, erorile se reduc vizibil, undeva la 60%. Iar daca facem estimarile dupa ce am gandit si designul software-ului, erorile se reduc si mai mult. Nu mai tin minte exact cifrele. In orice caz, mie mi s-au aprins niste beculete. Sper ca si voua :)

Posted by: Anda Sabau [Visitor] on 03/04/10 @ 14:44
Comment:

Salut,

Resursele sunt foarte interesante si utile cum a spus si Ioana in cariera si eventual lucrarea de licenta.

Mi-a placut foarte mult articolul acela Project management proverbs,intr-adevar o sursa de intelepciune,cred eu inspirate din experiente proprii si care ar trebui luate in considerare."The sooner you begin coding the later you finish" -il stiam si cred ca mi s-a intamplat si mie...se leaga oarecum de Mike Tarrani's Life Cycle, Project & Infrastructure Management Page prin faptul ca este necesara mai intai o planificare strategica a proiectului.
Too few people on a project can't solve the problems - too many create more problems than they solve.Si totusi in resursa aceea legata de imbunatatirea calitatii prin verificarea codului la cele 3 tehnici de verificare exista si avantaje in cazul utilizarii in acest scop al unui grup de persoane,desi probabil vor aparea si alte probleme...
Weekend placut!

Posted by: Vacarescu Andreea [Visitor] on 03/05/10 @ 20:35
Comment:

Hey,

Intr-adevar resursele sunt foarte interesante si utile si destul de numeroase.
Ce mi-a atras atentia a fost un chestionar intitulat Software Project Survival Guide -> http://www.construx.com/Page.aspx?hid=1229, nu atat pentru acuratetea probabila a estimarii facute cat mai degraba pentru intrebarile ce il alcatuiesc, intrebari care pot sumariza destul de complet ce pasi ar trebui urmati in fiecare etapa a dezvoltarii unui proiect de orice natura si de ce resurse trebuie sa dispuna respectivul proiect.
Cu ajutorul Google am descoperit si eu imaginea din URL-ul Ioanei - cred ca aparuse si prin slide-urile de la PDSS daca nu ma insel :) - oricum extrem de sugestiva si adevarata.Totodata un articol destul de scurt intitulat "Simplicity" cu un motto extrem de interesant: ?Making the simple complicated is commonplace. Making the complicated simple, awesomely simple, that?s creativity? ? Charles Mingus
iar in continuare 4 exercitii simple care prin natura lor au scopul de a imbunatati modul de a comunica in cadrul unei echipe si de a face intelese cat mai bine specificatiile de ambele parti (dezvoltator-client) -> http://ibslibrarychandigarh.wordpress.com/2008/05/16/
Consider ca este extrem de importanta comunicarea in cadrul unui proiect si existenta unei intelegeri clare a cerintelor pentru ca in final produsul obtinut sa satisfaca asteptarile celor direct interesati.Nimeni nu doreste sa finanteze un alt produs decat cel asteptat precum nimeni nu va cumpara un produs care face altceva decat pretind specificatiile.

Weekend placut!

Posted by: Dorian Blaj [Visitor] on 03/05/10 @ 23:29
Comment:

Salut,

Asa cum a fost mentionat deja in comentariile de mai sus, "Project management proverbs" reuseste usor sa capteze atentia. Poate pentru ca, as spune, se bazeaza pe expresii simple, usor amuzante la prima vedere dar care contin mult adevar.

Se vorbeste mult in ziua de astazi de "project management" si din nefericire multa lume considera ca acest concept se rezuma la impartirea unui proiect in mai multe etape, fiecare etapa fiind o bucatica din proiect iar la final, insumarea partilor se confunda cu finalizarea proiectului. Insa, de multe ori se omit tocmai aspectele care fac ca proiectul sa nu fie numai bine planificat ci si de calitate. Mie mi-au atras atentia mai mult articolele cu referire la diverse metrici, estimari, metode de asigurare a calitatii precum si domeniul managementul riscurilor. De ce se omit aceste directii intr-un proiect? Eu as indrazni sa mentionez urmatoarele aspecte: fie nu sunt foarte bine cunoscute fie exista o usoara temere fata de rezultatele acestor evaluari, rezultate pe care poate nu mai avem timp sa le imbunatatim. Dintre metricile de asigurare a calitatii as aminti review-urile si auditurile si recomand articolul :"Seven Deadly Sins of Software Reviews" http://www.processimpact.com/articles/revu_sins.html".

O alta metoda pentru imbunatatirea continua a unui proiect este metoda PDCA (plan-do-check-act) cunoscuta sub numele de Deming cycle. Este o metoda iterativa formata din 4 pasi/ciclu:
plan -stabilesti obiectivele, procesele care trebuie indeplinite si rezultatele asteptate,
do - implementarea efectiva a proceselor/obiectivelor,
check - verificarea ca ceea ce s-a asteptat a fost indeplinit,
act- se stabileste ce trebuie schimbat si cum pentru a imbunatati procesul si apoi se reia primul pas (plan).
Pentru mai multe info un link util ar fi: http://en.wikipedia.org/wiki/PDCA

numai bine,

Ioana Vedinas !

Posted by: Ioana Vedinas [Visitor] on 03/06/10 @ 00:20
Comment:

1. Ten Guaranteed Ways to Screw Up Any Project.
Am citit cateva dintre referintele furnizate si mi se pare mai interesant si util in primul rand sa intelegi
ce NU trebuie sa faci pentru ca proiectul sa nu fie un esec total.
In articolul http://michaelgreer.biz/?p=121 sunt prezentate astfel de greseli, pe care un leader de proiect neexperimentat le poate face foarte usor.
2. The Tale of Three Project Managers. O povestioara amuzanta despre tumultoasa aventura a managementului si elaborarii unui proiect.
http://www.hraconsulting-ltd.co.uk/project-management-tale.htm
Morala: tot ajungi la mal pana la urma.

Posted by: Gligor Mihai [Visitor] on 03/06/10 @ 02:10
Comment:

Buna ziua,

Ca si majoritatii celor ce au comentat pana acum, si mie mi-a placut siteul cu proverbe, legi si adevaruri din Project Management. Intr-un domeniu ca acesta, cu multa responsabilitate, putin umor este binevenit.

Al doilea articol pe care il aleg este "The Ethics of Software Project Management". Dupa cum se sugereaza in titlu, articolul abordeaza unele probleme de natura etica din cadrul Project Managemantului. Cred ca ar fi interesant sa avem la sfarsitul facultatii cateva cursuri despre etica din cadrul IT. Sunt sigur ca acest lucru ar contribui la calitatea muncii noastre.

Posted by: Alecsandar STOIANOV [Visitor] on 03/06/10 @ 15:16
Comment:

Buna ziua,

Primul articol care "mi-a facut cu ochiul" este cel referitor la Extreme Programming. De ce? Pentru ca am realizat ca asta este ceea fac in fiecare zi la servici. Chiar daca avem anumite targeturi fixe pentru un nou release la produsul la care lucrum, suntem (atat noi, cei care scriem codul, cat si project managerul) deschisi la eventualele probleme care apar pe vechiul release sau pe modificarile care sunt necesare urgent pentru ca cei care folosesc produsul sa il poata folosi la "parametrii maximi" oferind "on the fly" asa zisele hot fixuri. Cred ca daca nu am fi adaptabili si nu am fi "aproape" de clienti nostrii, acestia ar incerca sa gaseasca alte tooluri care sa umple golurile lasate de produsul nostru si astfel am avea de pierdut.

Al doilea articol care mi-a placut este cel referitor la standardele de calitate. De multe ori, cand un client doreste sa apeleze la o firma pentru a realiza un produs software "la cheie", clientul se informeaza daca respectiva organizatie detine un departament de calitate si mai ales daca este acreditata cu standarde din familia ISO 9000. Acest lucru spune multe despre respectiva organitie si mai ales ofera clientului un anumit factor de incredere, deoarece aceste standarde sunt auditate la o anumita perioada si daca ceva nu este gasit in regula, acreditarea este ridicata.

Toata cele bune,
Lucian Florea

Posted by: Lucian Florea [Visitor] on 03/06/10 @ 16:08
Comment:

Buna,

Eu m-am oprit asupra sectiunii intregi dedicate estimarii si metricilor utilizate in software project management. Tin se precizez ca lucrarea mea de licenta trateaza aceste aspecte si importanta lor.

Un prim articol interesant s-a dovedit a fi cel a lui Karl Wiegers, "Software Metrics: Ten Traps to Avoid". Intr-adevar, se dovedeste a fi destul de dificil sa estimezi corect (printr-o estimare buna se intelege aceea estimare care reda o imagine consistenta a realitatii pentru a putea permite managerilor de proiect si echipei de lucru sa ia decizii adecvate pentru a atinge fiecare tel propus al proiectului). Estimarile nu trebuie sa fie neaparat extraordinar de precise, ci mai degraba trebuie sa ai in vedere utilitatea lor.
Din acesta cauza, in literatura de specialitate se face referire uneori la estimare ca fiind o "arta neagra" [McConnell - Microsoft]. La prima vedere acesta afirmatie are sens: estimarea este ceva in deplin subiectiv. Pentru cineva care nu a estimat niciodata un proiect, nu cunoaste principiile si tehnicile utilizate, poate deveni echivalent cu prezicerea viitorului. Sigur, aceste afirmatii devin inutile daca reusim sa formalizam acest proces, interesant, de estimare, rezultand modele formale care ne ajuta sa estimam mai bine (ceea ce implica suprimarea la un minim a subiectivismului).

Un al doilea articol interesant, The Importance of Estimation, a paper (related to advertising) by the Software Productivity Centre, explica intr-o oarecare masura importanta estimarii. Estimarea este un pas important in realizarea planului de dezvoltare (efecte: daca nu se realizeaza o estimare buna, a costului de exemplu, poate avea efecte catastrofale in realizarea soft-ului si mai mult poti ajunge sa anulezi intregul proiect => nu mai ai bani, nu ai destul personal). Practic, o estimare buna duce la o garantie spre succes, dar nu succesul in sine. Ca un proiect sa fie de succes, trebuie aplicate si avute in vedere o serie de alte documente, unelete, metrici si nu in ultimul rand o planificare buna si un control bun asupra proiectului.

Concluzionand, as vrea sa spun ca desi intial am avut o impresie ca estimarea este o joaca, am avut supriza de a vedea o intreaga teorie asupra estimarii, o varietate larga de metode si abordari (de la metode formale la fuzzy, de la modele free ca si COCOMO la modele a caror pasi nu se cunosc in detaliu) si ca nimic nu e asa usor cum ai crede.


Un Weekend Placut,

Glad

Posted by: GHIBUS Glad [Visitor] on 03/06/10 @ 16:25
Comment:

Ceau!

Primul articol asupra caruia m-am oprit a fost Project Management Proverbs. Ceea ce mi-a atras atentia au fost vorbele intelepte legate de estimare...La serviciu, seful meu tot timpul ma pune sa estimez in cat timp voi termina ceea ce imi da de facut, si am observat ca estimatul nu e un lucru usor. La inceput estimarile mele erau gresite(desi incercam sa estimez logic munca necesara, implementarea, eventuale probleme)...acum incerc sa estimez mai realist(in functie de experienta anterioara), dar ajung sa pierd timp incercand sa fac o estimare corecta. Se intampla ca pentru doua task-uri asemanatoare sa fac estimari cu mult diferite, deoarece asa gandesc in acel moment...uneori cred ca estimatul e un fel de loterie.
El face acest lucru pentru ca eu sa ma obisnuiesc cu estimarile, deoarece in domeniul nostru ma voi lovi de ele, si trebuie sa invat sa estimez cat mai corect.

Al doilea articol care mi-a atras atentia a fost The Ethics of Software Project Management. Nu m-am gandit pana acum la proiectele software ca putand ridica probleme de etica. Dar vazand principii ca onestitate,considerarea costului social, actiuni eficiente si efective mi-am dat seama ca are sens aplicarea lor intr-un astfel de proiect. Acelasi lucru e valabil si pentru atentia ce trebuie acordata tuturor celor implicati intr-un proiect sau celor afectati de rezultatele acestuia.
Etica proiectelor software ar trebui avuta in vedere de mai multi manageri si dezvoltatori.

Va doresc un weekend placut!

Larisa Balosin

Posted by: Larisa Balosin [Visitor] on 03/06/10 @ 18:20
Comment:

Buna

Prima resura care mi-a atras atentia a fost din categoria Automated tools, si anume elementool. Mi-am facut cont ca sa inteleg despre ce ii vorba si cred ca este de mare ajutor pentru diploma de licenta. Se pot incarca documente, se pot conecta mai multe resurse pentru un proiect si se pot face estimari asupra proiectului in functie de task-urile atribuite respectivelor resurse(oameni), genereaza diferite rapoarte, se poate creea test case-uri care se pot delega la diferite grupuri de membrii sau doar membrii care participa la proiect si pentru comunicare are si un forum. Ei se lauda de foarte multi clienti printre care si companii care sunt ?n Fortune 500. Este un tool bun pentru managementul unui proiect.
Din aceeasi categorie de resurse am incercat si prima: "Software Methods and Tools" dar nu merge site-ul!
A doua resursa care am ales-o este din categoria Project management in general si anume: 4pm. Este un site dedicat certificarilor si pregatirii in acest domeniu. Ce mi s-a parut interesant este ca daca doresti sa urmaresti un curs ai un profesor personal ai cursul este inregistrat de experti in domeniu (si sunt filmate in natura :) ), nu ai limita de timp si profesorii sunt certificati cu experienta de mai mult de 10 ani.

O zi faina,
Bianca Florut

Posted by: Bianca Florut [Visitor] on 03/06/10 @ 23:23
Comment:

Buna ziua,
Domeniile despre care am ales sa vorbesc sunt Quality Issues si Rick Management. Motivul? sunt complexe, nu oricine poate face treaba buna in aceste domenii, si bine platite.
Spre exemplu(asa cum este exemplificat pe linkul: http://www.processimpact.com/articles/principle.html) Quality Assurance Managers sunt cei care trebuie sa impace lumea, ei sunt cei care trebuie sa asigure ca designer-ul nu o i-a rasna in proiectare, si nu depaseste cerintele proiectului, el trebuie sa impace stakeholderii motivand fiecare actiune si (din putina experienta pe care o am chiar trebuie sa duca o lupta grea cu ei pentru a primii resursele necesare pentru a duce proiectul la bun sfarsit si cu un nivel de calitate ridicat) si unpic surprinzator pentru mine e ca tot ei trebuie sa interpreteze cerintele clientului si sa le transpuna in ceva real, ieftin care merita efortul si cu un nivel de calitate ridicat,chiar daca nu le respecta exact, trebuie sa-si asume acest risc deoarece pe termen lung clientul va castiga. Ei trebuie sa asigure ca nu se intampla ce este reprezentat in poza pusa de Ioana Bota (Csiri) la primul comment.
Pe scurt acestea sunt cateva din atributiile managerului de calitate, (cele mai importante din punctul meu de vedere).
Acum sa trecem la inca un post pe care eu personal il admir, si anume Risk Manager. Traim intr-un mediu din ce in ce mai nesigur. Cu siguranta criza financiara ne-a afectat pe fiecare in parte, intr-o oarecare masura. Dar cel mai mult au fost afectate firmele, firmele mari cu proiecte de lunga durata.Risk managerul a devenit o piesa importanta in luarea deciziilor. Atributele acestuia se imbina intr-o oarecare masura cu cele ale Quality Assurance Manager, si sa fim seriosi, seful v-a inclina balanta intotdeauna spre Risk Manager.

Best Regards,
Ionut Costan

Posted by: Costan Ionut [Visitor] on 03/06/10 @ 23:40
Comment:

Ciao,

Urmarind unul dintre linkurile lui Mihai am ajuns la un articol interesant: So you want to be a project manager? http://www.hraconsulting.fsnet.co.uk/project-management-training-course-uk.htm
Articolul subliniaza importanta faptului ca managerul de proiect sa fi fost la un moment dat programator, precum si capacitatea acestuia de a fi un "good people manager". Din punctul meu de vedere, relatiile dintre colegi sunt esentiale pentru succesul unui proiect si recunosc ca am avut rezultatele cele mai bune la proiectele in care am facut echipa cu prieteni. Asa ca "Make the project fun!" e un sfat care ar trebui urmat de orice project manager.

Despre importanta relatiilor dintre colegi am citit si in Seven Deadly Sins of Software Reviews http://www.processimpact.com/articles/revu_sins.html
Aici ni se spune sa criticam produsul si nu autorul lui si mi-am dat seama ca de multe ori avem tendinta sa acuzam o persoana pentru greselile pe care le-a facut, iar aceasta nu are alt rezultat decat sa-l faca pe autor sa se simta prost.
Sentimentul de colegialitate poate conduce insa si la lucruri mai putin dorite, in sensul ca e posibil ca unele greseli sa nu fie raportate pentru a nu pune un coechipier intr-o lumina proasta in fata sefului.

Sper ca in proiectele pe care le vom avea de realizat sa gasim o modalitate de a face munca sa para "fun".

Andrada

Posted by: Andrada Rupacici [Visitor] on 03/07/10 @ 11:59
Comment:

-Project Management Proverbs
"A problem shared is a buck passed."
Poate unii dintre noi se intreabu mai demult de ce companiile de renume pun asa de mult pret pe caracterul si deschiderea spre socializare in momentul angajarii.Un raspuns scurt ar fi : pentru ca este important.De ce este atat de important? pentru ca ne aflam intr-o lume in care volumul informatie este extrem de mare, nu mai poate fi acoperit nici pe sfert cat ar fi putut fi asimilat acum sa zicem 15-20 ani (noi tehnologii, noi limbaje de programare , care au aparut din necesitatea rezolvarii unor probleme noi sau pt optimizarea solutiilor gasite pt niste probleme vechi).De aceea lucrul in echipa, este cuvantul cheie deoarece zilnic ne lovim de probleme la care nu gasim o solutie imediata sau nu gasim o solutie eficienta care sa ne satisfaca, aceasta problema transformandu-se intr-o provocare.O data rezolvata problema, fie ca prin forte proprii fie cu ajutorul colegilor, ideal ar fi ca ea sa fie impartasita si altora pentru ca si acestia la randul lor sa aibe ceva de invatat din ea.

-Seven Deadly Sins of Software Reviews http://www.processimpact.com/articles/revu_sins.html
Un articol destul de interesant despre ce Nu ar trebui facut in timpul unui review pentru nu a afecta rolul pe care acesta il il are in procesul de dezvoltare al unui produs software.Cateva dintre greselile importante care se pot face sunt : alegerea unor persoane nepotrivite pentru revizuirea task-ului,lucru care poate anula beneficiile aduse de aceasta metoda ,reviewerii sunt nepregatiti.Toate acestea rezulta din faptul ca developerii nu sunt constienti de importanta acestor review-uri si de probleme care pot fi evitate inca de timpuriu intr-un proiect doar daca review-ul este realizat asa cum trebuie.A second look, o a doua parere ar trebui sa fie oricand bine primita de fiecare dintre noi cat si vice versa adica ar trebui la randul nostru sa oferim suport colegilor prezentandu-le ideile noastrea.La asta se refera de fapt procesul de review care are ca scop descoperirea timpurile a posibilelor erori, bug-uri care pot aparea pe viitor in proiect.

Posted by: Loredana Gancea [Visitor] on 03/07/10 @ 13:04
Comment:

Buna ziua ,

Un prim articol ce mi s-a parut util este "The Ethics of Software Project Management". Pe langa punctele
traditionale intalnite in acest
domeniu ( alegerea metodologiei , estimarea dimensiunii proiectului , identificarea resurselor ce pot fi reutilizate ) aici este prezentat un alt punct de vedere asupra project management. Cum nu eram foarte familiar cu aceste " cerinte etice " , mi s-a parut foarte interesant sa aflu ca acestea pot fi chiar impartite in 8 Principii ca : Honour , Honesty , Fairness , etc. In plus , se pare ca primul pas din dezvoltarea unui proiect
trebuie sa satisfaca cele mai multe cerinte etice , 6 la numar( fapt ce se dovedeste a fi in concordanta cu realitatea si cu ce se asteapta de la un proiect
software ).

Al doilea articol ales este " The Importance of Estimation ". Procesul de estimare este descris ca fiind un factor determinant pentru rezultatul unui proiect IT. Tocmai de aceea , acest proces este unul foarte dificil pentru majoritatea companiilor(fapt sustinut de o statistica care arata ca mai mult de 66% din proiecte
nu sunt in stadiu final la deadline , nu au respectat bugetul estimat si in plus , calitatea este sub ce se astepta). Desigur , o estimare corespunzatoare nu ma asigura ca proiectul final va fi un succes imens , insa ofera o anumita stabilitate (foarte necesara) in dezvoltarea acestuia.

O zi placuta

Posted by: Ovidiu Purcaru [Visitor] on 03/07/10 @ 13:13
Comment:

Articolele legate despre riscurile proiectelor mi s-au parut foarte interesante si foarte utile. Cred ca, in ceea ce priveste deciziile care se iau in realizarea unui proiect software, nu se poate gasi decizia care este 100% fara riscuri. De aceea, manager-ului de proiect ii revine responsabilitatea de a gasi calea care implica cele mai putine si cele mai mici riscuri. Aceasta cale este greu de gasit, mai ales daca manager-ul de proiect este lipsit de experienta. In acest caz (cazul nostru) este foarte util sa studiem si sa invatam din greselile altora, pentru ca (asa cum spune un proverb) viata este prea scurta pentru a le face singur pe toate. Exerientele descrise in The Risck digest mi se par foarte folositoare.

Pentru a da un calificativ unui proiect software, acesta trebuie analizat din mai multe puncte de vedere. De aceea, "piramida" din articolul "Are we there yet?" mi-a atras atentia: work environment, defects, project cost, time to release, feature set, people and their capabilities.

Posted by: Giura Georgeta [Visitor] on 03/07/10 @ 14:32
Comment:

Salut,
Citind articolul de pe projectconnections.com legat de analiza SWOT am inteles ce este si de ce e necesara o astfel de analiza. SWOT este prescurtarea de la Strengths, Weaknesses, Opportunities, and Threats. Prin realizarea unei astfel de analize se pot prioritiza diferitele parti dintr-un proiect, se clarifica cerintele si poate reprezenta un factor decisiv in luarea unor decizii.

Alt articol facea referire la un dictionar de termeni folositi in project management. Unii erau cunoscuti si pareau logici (ex. Project plan), altii erau necunoscuti (sarbox), iar altii desi aveau inteles cuvintele, nu puteai sti la ce se refera exact daca nu citeai definitia (project plan). Mi se pare foarte important sa ai la indemana un astfel de dictionar pe care sa il consulti din cand in cand pentru a aprofunda termenii folositi.Un link catre astfel de dictionar este: http://glossary.tenrox.com/

Posted by: Marius Cojocaru [Visitor] on 03/07/10 @ 19:45
Comment:

Buna ziua,
deoarece nu eram in clar cu ce inseamna mai exact project management,m-am decis sa citesc - A free on-line course on software project management by SoftwareProjects.Org - un site folositor oricarui om care nu e in tema cu project management!A doua resursa care mi-a atras atentia a fost - Risk Benefit Analysis at wustl.edu - foarte utila,in care se vorbeste despre punerea in balans a riscurilor pentru a obtine beneficii.
O zi buna in continuare.

Posted by: Razvan Placintar [Visitor] on 03/07/10 @ 19:52
Comment:

Tinand cont ca unul din filmele mele preferate e ?7even?, primul articol care mi-a atras atentia a fost ?Seven Deadly Sins of Software Reviews? al lui Karl Wiegers. In acest articol ne sunt descrise 7 probleme care apar in majoritatea review-urilor software, precum si solutii pentru prevenirea si rezolvarea lor. Cea mai importanta problema o consider a fi cea in care la un review se critica autorul produsului si nu produsul in sine. Asa cum spune si autorul atunci cand se critica abilitatile si stilul unui autor, acesta se va simti direct atacat, lucru care ii poate afecta mult munca si relatiile cu ceilalti colaboratori la proiect. Unul dintre sfaturi e sa ne concentram toata atentia asupra imbunatatirii calitatii produsului si nu asupra cui cade vina. Un sfat bun de urmat si in viata de zi cu zi as adauga eu.

Trecand de la problema calitatii la cea a metricilor si a estimarilor m-am oprit asupra articolului ?The importance of estimation?. Sunt de parere ca o estimare buna a costului, a timpului si a multor alte elemente cheie te va scapa de multe probleme. Insa aceste estimari sunt foarte greu de realizat in cazul unor proiecte software. Cei de la Software Productivity Center vin in ajutorul managerilor de proiect, oferindu-le un fel de test intitulat sugestiv ?Estimation needs assessment?. Rezultatul testului se calculeaza in functie de numarul de intrebari la care ai raspuns cu ?nu?.Foarte dragut.

O saptamana cat mai buna!
FASIE Marieta

Posted by: Fasie Marieta [Visitor] on 03/07/10 @ 20:00
Comment:

Salut,

Se pare ca tuturor ne plac proverbele. Desi majoritatea dintre ele au o tenta umoristica cred ca daca in cadrul unui proiect s-ar lua in calcul macar jumatate din aceste proverbe, sansele ca proiectul sa fie un success ar fi destul de mari, deoarece proverbele ne ajuta sa evitam sa facem aceleasi greseli care au fost facute de alte persoane inaintea noastra.

The Importance of Estimation. Cred ca cel mai important factor care influenteaza realizarea unei estimari cat mai corecte este conoasterea cat mai buna a membrilor echipei angajate in realizarea unui proiect.

Posted by: Bolovan Andrei [Visitor] on 03/07/10 @ 20:04
Comment:

Am ales un articol scris de Ann DrinkWater de pe blogul ProjectConnections.Ann scrie in articolul ei despre spiritul, dedicarea atletilor de la Olimpiada si despre lectiile pe care le-am putea invata si aplica in viata personala si profesionala.
Ea vorbeste despre pasiunea pe care ar trebui sa o avem pentru ceea ce facem zi de zi,energia pe care ar trebui sa o depunem sa obtinem performante bune atat individual cat si in cadrul unei echipe, despre cum sa fii un exempu pentru cei din jur.
"The spirit of the games can and should live in all of us".
Sunt de acord ca avem multe de invatat de la acesti sportivi dar nu cred ca o sa pot face vreodata o comparatie intre un proiect la lucru si o astfel de competitie.


Al doilea articol ales e scris de Lisa DiTullio - A Winning Team. Lisa scrie despre alegerile pe care trebuie sa le faca un project manager atunci cand isi construieste echipa.Esti ales ca si la fotbal in curtea scolii pentru calitatile fizice sau pentru ca esti prieten cu capitanul echipei? Fiecare project manager trebuie sa se gandeasca bine de ce membri are nevoie in functie de marimea,tipul,importanta proiectului.

Posted by: Victor Gavrila [Visitor] on 03/07/10 @ 20:24
Comment:

Articolul care mi-a atras atentia in mod deosebit a fost cel legat de modul in care este nevoie sa ne construim echipele atunci cand lucram la un proiect.Astfel pe acest site :http://www.smallbusinessdelivered.com/fivecharacteristicsofagreatteam.html sunt prezentate 5 regului de baza care ar trebui sa stea la baza construirii unei echipe de lucru puternice si de succes :respectul,ajutorul dar mai ales increderea intre coechipieri sunt mai mult decat necesare.Tot odata dorinta tuturor de a indeplini telul impreuna va avea ca rezultat obtinerea unui proiect care sa satisfaca cerintele clientului.Cel mai importatnt aspect insa este legata de atributiile managerului de a imparti sarcinile corecte fiecarei persoane implicate in dezvoltarea proiectului.
Un alt articol care mi-a placut a fost cel legat de Software Project Survival Test: cele 31 de intrebari mi s-au parut foarte interesante si constructive in vederea realizarii unei imagini clare asupra proiectului dezvoltat.

Posted by: Peto Beatrice Adela [Visitor] on 03/07/10 @ 20:27
Comment:

Buna,

Urmaresc atenta cele scrise de voi; ma bucur ca v-ati aplecat cu interes asupra acesta exercitiu si ati gasit aspecte interesante si utile.

Sigur si urmatoarele contributii vor fi la fel de bine argumentate.

O seara placuta tuturor,
Carmen Holotescu

Posted by: Carmen [Member] on 03/07/10 @ 20:35
http://www.timsoft.ro
Comment:

Buna,
Cred ca inainte de a incepe un proiect, dar si in timpul dezvoltarii acestuia este foarte important sa cunoastem riscurile si ce impact pot avea acestea asupra proiectului.Am citit articolul "Risk-Benefit Analysis" (http://capita.wustl.edu/ME567_Informatics/concepts/riskben.html) si ,cu toate ca nu m-am gandit pana acum la asta, sunt de acord ca actiunile involuntare ne aduc riscuri mult mai mici decat cele voluntare.

Am citit apoi articolul "Time-tiger" .Consider ca si timpul este foarte important pentru un proiect si ca pentru dezvoltatorii de proiecte este folositor sa foloseasca Time Tiger, sau altele asemanatoare.Deasemea este util si pentru viitoarele proiecte sa ai o evindenta a impactului timpului asupra proiectelor anterioare, pentru a vedea unde ai gresit in managementul timpului si sa nu faci aceleasi greseli.

O seara placuta,
Bianca Popesc

Posted by: Popesc Bianca [Visitor] on 03/07/10 @ 20:43
Comment:

Salut,


Eu am citit despre risk management si mi s-a parut interesanta ideea ca oamenii isi asuma mult mai multe riscuri atunci cand actiunile lor sunt voluntare si ei pot sa controleze situatia. Comparatia cu aviatia mi s-a parut foarte potrivita.Multi oameni considera ca riscul de a zbura este mai mare decat cel de a conduce, dar din punct de vedere statistic acest lucru nu este corect. Fenomenul se explica prin faptul ca conducand masina ei sunt cei care controleaza situatia si astfel percep riscurile ca fiind mult mai mici decat atunci cand trebuie sa se bazeze pe un pilot.

Un alt articol interesant este cel despre software estimation in care se descrie importanta estimarii corecte a costurilor, a termenului de livrare si a resurselor necesare. Mi-am dat seama cat de important este pentru clienti sa detina aceste informatii. O estimare corecta le confera incredere in faptul ca proiectul va fi o reusita si va duce la o colaborare buna si stabila.

Posted by: Ordodi Timea [Visitor] on 03/07/10 @ 20:46
Comment:

1. http://www.processimpact.com/elearning.shtml#pmbp

Project Management Best Practices

Aceasta resursa vorbeste despre aplicarea unor practici de succes in Project Management, practici care se bazeaza pe studiul industriei, pe succesul si esecul altor proiecte si experienta personala a autorului.



2. http://www.processimpact.com/webinars.shtml#spitraps

Software Requirements:10 traps to avoid

In acest Webinar se arata cum multe organizatii de dezvoltare pot cadea in anumite capcane care le previn de la colectarea,documentarea si managementul corect al cerintelor. Aceasta prezentare descrie 10, cele mai tipice, probleme de cerinte care pot sabota un proiect si simptomele care pot indica daca esti prins intr-o astfel de capcana.

Posted by: Adrian Cazan [Visitor] on 03/07/10 @ 20:48
Comment:

Ceau,

Cele 2 articole citite de mine au ca tema risk management. Primul, "Risk-Benefit Analysis", este foarte scurt si concis. Ideea de baza a acestuia este ca riscul face parte din cotidian, dar este interpretat in mod diferit in functie de cei care fac evaluarea. Este prezent un exemplu privind transportul aerian unde compania de asigurari evalueaza riscul raportandu-se la statistici, iar un pasager face evaluarea in mod intuitiv.
Al doilea articol este cel de la pagina: http://www.sei.cmu.edu/acquisition/start/work/index.cfm unde se face o introducere scurta a suitei de metode numita Mosaic ce este folosita in analiza top-down a riscului intr-un proiect software. Aceasta a aparut ca raspuns la tehnica bottom-up. Aceasta este abordare tactica in analiza riscului, dar nu ofera de la inceput o imagine de ansamblu si astfel multe proiecte sunt destinate esecului.
In concluzie o analiza a riscurilor este recomandata in cadrul oricariu proiect si trebuie facuta astfel incat sa cuprinda diversele puncte de vedere ale evaluatorilor.

Posted by: Ramona Croitoru [Visitor] on 03/07/10 @ 20:51
Comment:

Primul ar fi 'Ten Guaranteed Ways to Screw Up Any Project' ( http://michaelgreer.biz/?p=121 ). Prezinta o serie de moduri/motive din cauza caruia un proiect sau o serie de proiecte pot esua. Majoritatea avand ca fundament tendinta managerilor de proiect de a 'overdo it', de a perfectiona sau de a concentra prea multa atentie in puncte care nu necesita acest lucru.

Al doilea articol ar fi 'Project Management Proverbs' ( http://www.project-training-uk.freeserve.co.uk/ ). Acesta prezinta o serie de proverbe, unele comice, altele mai serioase (mai ales privite prin prisma societatii noastre) despre modul in care ar trebui luate deciziile in privinta unui proiect. Acestea vin din partea opusa cea a primului articol, punand accentul pe faptul ca unele lucruri trebuie neaparat facute. De asemenea, pe acelasi site, se pot gasi o serie de legi si adevaruri despre Project Management.

Posted by: Oros Adrian [Visitor] on 03/07/10 @ 21:19
Comment:

Buna seara,
Resursele sunt multe, interesante si utile, ai de unde alege si citi/invata despre acest domeniu :-).
Unul dintre cele mai interesante proverbe (dintre Project Management Proverbs) mi s-a parut "Any project can be estimated accurately (once it's completed)." Perfect de accord :-P
Linkul catre "One Hundred Rules for NASA Project Managers" este broken, pdf-ul il puteti scoate de aici:http://www.projectsmart.co.uk/docs/100-rules-for-nasa-project-managers.pdf. Cuprinde o lista de sfaturi excelente atat pentru managerii la inceput de drum, cat si pentru cei cu experienta.
Care sunt competentele unui bun Project Manager? Nu m-am putut abtine sa nu pun intrebarea, si daca tot am scris-o, dau si un raspuns :P
Un Project Manager trebuie sa detina cunostinte cat mai vaste in diverse arii de Management, trebuie sa inteleaga si sa-si asume business case-ul propus pentru scopul proiectului respectiv.
PMBOK (Project Management Body of Knowledge) prezinta noua arii de competente dupa cum urmeaza:
Integration Management - integrarea tuturor informatiilor provenite din varii surse este cruciala
Scope Management - puterea de a pastra proiectul in parametrii stabiliti si de a spune nu cand este cazul
Time Management - sa stie sa-si gestioneze propriul timp si sa faca estimari realiste asupra timpului altora
Cost Management - cunostinte de tip financiar, previziuni si control
Quality Management - atentia la calitate, metode prin care sa atinga standardele cerute
Human Resource Management - leadership, motivare, recrutare
Communications Management - comunicare atat formala cat si non-formala
Risk Management - anticiparea riscurilor si a oportunitatilor, gestionarea acestora
Procurement Management - cunostinte din sfera legal, purchasing, abilitati de negociere
Doua carti interesante mi s-au parut "How to Cheat at IT Project Management" si "A Guide to the Project Management Book of Knowledge - PMBOK Guide - Fourth Edition".

O seara placuta tuturor :)

Posted by: Bogdan Petrutescu [Visitor] on 03/07/10 @ 21:28
http://www.bookblog.ro/
Comment:

Revin cu 2 linkuri pentru cele 2 carti.

Pentru "How to Cheat at IT Project Management" un review gasiti aici -> http://blogcritics.org/books/article/book-review-how-to-cheat-at/.

"A Guide to the Project Management Book of Knowledge - PMBOK Guide - Fourth Edition", un review gasiti aici -> http://www.projectmanagementdocs.com/articles/pmbok-guide-book-review.html

Numai bine

Posted by: Bogdan Petrutescu [Visitor] on 03/07/10 @ 21:35
http://www.bookblog.ro/
Comment:


Pentru ca aveam deja o idee generala despre managementul proiectelor, mi-a atras atentia din start metoda de "extreme programming" si felul cum intregul proces de creatie al software-ului capata o dinamica mai rapida (ceea ce nu poate fi decat de ajutor, chiar si pentru licenta pe ultima suta de metri :) ). Ideea centrala in XP este structurarea evolutiei proiectului in functie de cerintele clientului si oferirea responsabilitatii acestuia pentru a determina ce functionalitati sunt mai importante (si mai urgent de implementat). Echipa se axeaza pe oferirea cat mai rapida a unui produs functional si implementarea de noi caracteristici in functie de alegerile clientului si de modificarea cerintelor. Perspectiva se inverseaza, cerintele sunt privite ca fiind variabile, iar procesul de lucru este continuu.

Un alt articol interesant tine de etica managementului proiectelor software. La prima vedere asemenea considerente nu par sa influenteze atat de mult viata unui proiect software, dar pe masura ce procesul progreseaza, vor aparea momente in care anumite decizii importante depind in mod real de etica celor implicati. Prin urmare, solutia consta intr-un management etic, adica dezvoltarea unei viziuni de ansamblu in care rolul principal il au scopul si cerintele proiectului, iar aceasta se obtine prin stabilirea spatiului de influente asupra proiectului - cine sunt stakeholder-ii? care este gradul lor de implicare? In general reflectia asupra eticii tine de inteligenta sociala a managerului, ceea ce duce direct la definirea atitudinii intregii echipe.

Pe pagina sunt foarte multe linkuri interesante, numai timp sa fie pentru toate :)

O seara frumoasa

Posted by: Andrei Dumitrescu [Visitor] on 03/07/10 @ 21:44
Comment:

Citind articolul "Five characteristics of a great team" mi-am dat seama că regulile propuse de Shirley Fine Lee nu se aplică ?ntotdeauna, respectiv sub aceeaşi formă şi pentru proiectele software. Experienţa de p?nă acum mi-a arătat că responsabilitatea leadership-ului este atribuită după nişte reguli nescrise (mai concret: level of skill, expresivitate, concreteţe) unui membru al echipei şi tinde să răm?nă fixată, tot după reguli nescrise (nu ?ncearcă nimeni să provoace vreo schimbare, cel puţin) p?nă la sf?rşitul proiectului. Asta se ?nt?mplă pentru că, de cele mai multe ori, nivelul de pregătire al membrilor echipei variază iar lider va fi "numit" cel care reuşeşte să se afirme cel mai bine din acest punct de vedere. Liderul are, de asemenea, datoria de-a motiva echipa şi, privindu-i membrii din această perspectivă, ?l putem identifica pe acela capabil să o facă cel mai bine.
De asemenea, am avut ocazia să observ că mulţi software developers se descurcă mult mai bine ?n perimetrul unor specificaţii bine stabilite (pe care trebuie să le implementeze) şi a căror performanţă scade atunci c?nd sunt implicaţi ?n procese de decizie la un nivel superior. Implicarea lor ?n alte activităţi ar avea un impact negativ asupra performanţei echipei.
Aş dori să adaug că o proprietate importantă a echipei care dezvoltă un proiect software este numărul membrilor săi. O echipă mare tinde să fie mai degrabă dezorganizată şi productivitatea ei e mai mică dec?t productivităţile membrilor ?nsumate. Acest lucru se datorează at?t unui management care nu mai poate gestiona corect resursele disponibile c?t şi nevoii de comunicare ?ntre un număr mare de persoane. Pe undeva, o astfel de echipă se plasează cu totul ?nafara regulilor propuse de Shirley Fine Lee (iar relevante fiind mai degrabă primele două).

"Project management proverbs" mi-a plăcut ?n mod deosebit, citindu-le fără să-mi pot reţine un "aşa-i dom-le" pe-un z?mbet. Z?mbetul a fost trist ?nsă, c?nd am ajuns la "What you don't know hurts you."

Posted by: Valeriu Chis [Visitor] on 03/07/10 @ 21:50
Comment:

Despre "Time Tiger from Indigo Technologies"
Eram curios ce face un astfel de tool si daca ar fi cu adevarat de folos.
Tind sa spun ca ar face mai mult rau decat bine. In primul rand necesita
ca toti cei care lucreaza la proiect sa faca update cat mai des posibil. Acest lucru i-ar permite managerului sa intervina daca proiectul ramane in urma si in general sa mentina lucrurile sub control. Dar se poate intampla ca acest update sa nu se faca, sa se faca prost sau sa puna presiune suplimentara pe membrii proiectului. Cred ca orice tool este folosit mai mult pt. ca "da bine" pt. o companie si mai putin pentru ca este intr-adevar folositor.


Simteam nevoia sa ma relaxez dupa primul comentariu, asa ca am ales ceva mai lejer,Project Management Proverbs.
Am extras cateva citate mai semnificative :
The most valuable and least used WORD in a project manager's vocabulary is "NO".
The most valuable and least used PHRASE in a project manager's vocabulary is "I don't know".
A badly planned project will take three times longer than expected - a well planned project only twice as long as expected.
The person who says it will take the longest and cost the most is the only one with a clue how to do the job.

Va recomand sa le cititi pe toate, sunt cu adevarat amuzante.
Asta pana in momentul in care constati ca te afli exact intr-una din aceste situatii si lucrurile se indreapta mai degraba spre tragic decat comic..

Posted by: Florin SIRBU [Visitor] on 03/07/10 @ 21:59
http://none
Comment:

Buna,

O alta metoda folosita tot mai des in Project Management si pe care eu o recomand este cea de Agile Management. Una din metodele de aplicare se numeste SCRUM. Prin punerea in practica aceasta metoda s-a dovedit foarte eficienta datorita imbunatatirii lucrului in echipa, datorita cooperarii mai apropiate intre echipa si client(datorata in principal livrarii proiectului in iteratii scurte) si comunicarii mai bogate(Daily Scrum meeting).

O carte care mie mi s-a parut interesanta si care trateaza unele aspecte de Project Management , cu accent pe lucrul in echipa este : Peopleware scrisa de Tom DeMarco & Timothy Lister.

Slavita

Posted by: Slavita Baciuna [Visitor] on 03/07/10 @ 22:03
Comment:

Primul lucru despre care am citit este un tool de planificare a activitatilor/task-urilor intr-un proiect software. Ma refer la PlanBee care propune o maniera de utilizare simplificata si cu care poti programa deadline-urile diverselor etape prin care trece un produs software de la "nastere" la release si la versiunile ulterioare.

Pe masura ce sunt finalizate anumite componente ale produsului acestea pot fi introduse in acest tool si un project manager poate observa usor care este stadiul lucrului defalcat pe fiecare componenta importanta in parte. Astfel, pt un project manager este mai usor sa coordoneze echipa, stie mai repede care echipa de programatori e mai "lenesa" putand sa suplimenteze nrul de programatori sau sa ii reduca, dupa caz.

Al doilea articol pe care l-am citit se refera la Risk Management si concluzia este ca nu e usor sa fii project manager in sensul ca responsabilitatea pe care o are fiecare programator in parte se insumeaza asupra managerului de proiect.
Acesta este adesea pus in situatia de a-si asuma riscuri precum a da aprobarea de release a unui produs care contine unele buguri versus a amana releasul pentru a repara bugurile. Aici trebuie analizate si caracteristicile acestor buguri si anume: sunt grave?, sunt usor de corectat?, sunt rapid de corectat?, nu se "strica" altceva daca le corectez pe acestea?, acele buguri apar in situatii obisnuite pe care un utilizator le va intalni des sau situatiile in care un utilizator poate da peste aceste buguri sunt foarte rare? . Iata ca aceste situatii de risc trebuie cantarite atent si pot face diferenta intre un produs de succes si un fiasco ce va incinge liniile de suport tehnic.

Posted by: Silviu Lung [Visitor] on 03/07/10 @ 22:08
http://tanagranoise.blogspot.com/
Comment:

Ceau,

Am cautat intentionat sa citesc un articol despre estimarea timpului pentru ca la serviciu foarte des mi se pune intrebare: cat timp crezi ca iti ia sa faci asta? La inceput tot n-am inteles ce ma tot intreaba de fiecare data cat timp iti ia si am tratat cu superficialitate acest aspect insa mi-am dat seama pe parcurs de importanta unei bune estimari.
Am vazut ca exista ceva tool-uri care te ajuta sa-ti imparti mai bine timpul insa acum cred ca un lucru foarte important este sa-ti fie tie clar ceea ce trebuie sa faci, sa ai o buna cuprindere si structura a tot ceea ce urmeaza sa faci. O buna estimare se mai perfectioneaza si in timp si vine din experienta insa trebuie sa fim constienti de importanta acesteia. Mai mult cred ca estimarea timpului poate fi utila si in proiecte si actiuni din viata personala nu doar in programare.

Al doilea articol ce l-am citit a fost cel cu proverbe: si-am gasit completarea la cel cu estimarea: estimarea adevarata o faci la sfarsitul proiectului cand vezi cat a durat:)
Au fost mai multe proverbe dragute o parte deja cunoscute. Putin neasteptat dar adevarat daca la un proiect deja intarziat mai adaugi oameni noi va intarzia si mai mult.

Teo

Posted by: Teodora Cociuba [Visitor] on 03/07/10 @ 23:05
Comment:

Buna,

De mult timp am avut o mica pasiune pentru NASA: am vazut multe documentare despre proiectele NASA, despre astronauti de la nasa, despre ingineri etc, insa niciodata nu mi-am pus problema ce proces de management sta in spatele acestei organizatii.
La o trecere in revista a resurselor de pe site, primul lucru ce mi-a sarit in ochi a fost tema: "One hundred rules for NASA project management". Linkul nu functioneaza, dar nici o problema ca exista Google si in cele din urma am ajuns la pdf-ul in cauza. Citind cele 100 de reguli imi pot imagina cum de organizatie e asa de mare si de puternica.
Dar daca tot suntem ingineri vreau sa ma opresc la regula 55: "Over-engineering is common. Engineers like puzzles and mazes. Try to make them
keep their designs simple", regula cu care sunt intru totul de acord. De ce spun acest lucru? Pentru ca am observat din proprie experienta ca ori de cate ori un proiect se complica inutil, incep sa apara problemele.
O alta regula care cred ca multi dintre noi ar trebui sa o avem in minte cand facem parte dintr-un proiect ar fi 74: "All problems are solvable in time, so make sure you have enough schedule
contingency, if you don't, the next project manager that takes your place will".

Un al doilea link care mi-a atras atentia este: Project management guides. Cred ca e interesant de citit si contine sfaturi utile ce merita citite.
Cred ca oricine incepe un proiect nou trebuie sa il inceapa gandindu-se ce aduce el nou prin proiectul respectiv. Si tot odata sa aibe in permanenta evidenta timpului, resurselor si a performantelor de criterii si sa planifice proiectul in asa maniera in cat sa ia in considerare cat mai multi factori de risc.

Si as dori sa imi inchei aceasta opicie tot print-un citat din cele 100 de regului de la NASA: "Wrong decisions made early can be recovered from. Right decisions made late cannot correct them."

Posted by: Ioana Negoita [Visitor] on 03/07/10 @ 23:25
Comment:


Imi cer scuze pentru lipsa paragrafelor si forma bloc a comentariului meu anterior. Nu a fost intentionata!:(

Posted by: Andreescu Oana [Visitor] on 03/08/10 @ 00:07
Comment:

Nicio problema, Oana, lipsea optiunea auto-BR; am setat-o eu pentru comentariu, asa incat acum apar paragrafele.

Numai bine,
Carmen H

Posted by: Carmen [Member] on 03/08/10 @ 00:12
http://www.timsoft.ro
Comment:

Buna ,

Am "rasfoit" putin linkurile si sunt cateva care mi-au atras atentia. Dintre acestea 2 sunt urmatoarele:

Risk Management:
- Din punctul meu de vedere, managementul riscului este o componenta foarte importanta a managementul proiectului. Managementul riscului presupune evaluarea riscului si analizarea lui in contextul tuturor factorilor ce influenteaza proiectul.
Un manager de risc este cel care decide daca riscurile proiectului sunt acceptabile din punct de vedere al costurilor pe care pot sa le ridice, daca beneficiile produsului sunt mai mari decat riscurile care pot aparea. Un manager de risc decide ce se va face in privinta riscurilor, iar deciziile lui sunt subiective (pot tine de personalitatea sa , de experienta , etc).

Seven Deadly sins of software reviews: s-a constatat ca examinarea manuala a unui produs ajuta la detectarea defectelor. Totusi, aceasta examinare nu este intotdeauna incununata cu succes, datorita dificultatii cu care organizatiile se confrunta in realizarea software review. Cateva probleme care apar sunt:
- participantii nu inteleg procesul
- participantii nu critica produsul , ci critica producatorul
- controlul produsului nu este planificat
- intalnirile de control al produsului se abat de la subiect, si devin incercari de a rezolva problemele deja gasite
- participantii la intalnirile de review nu sunt bine pregatiti
- nu participa oamenii potriviti

Acest proiect se anunta a fi foarte interesant, si abia astept sa fim manageri.

O seara placuta,
Adriana

Posted by: Adriana Neicu [Visitor] on 03/08/10 @ 00:22
Comment:

Am vizitat majoritatea link-urilor indicate, bune si rele. Unele utile, altele si interesante, cateva simpatice, altele presarate si cu un strop de umor, cateva la care prezentarea lasa de dorit, dar si niste link-uri care au plecat undeva pe campii mai verzi, sau numai s-au mutat dar au ramas printre noi.

Cel mai mult mi-au placut sfaturile practice ale lui Karl Wiegers din care se pare ca pe site au ramas in prezent doar niste worksheet-uri scurte si la obiect, care abia asteapta sa fie completate. Probabil ca era o vreme demult trecuta cand exista pe site si cartea sa, nu numai link-ul catre amazon si minunatele cursuri platite de e-learning.

Trecand si la lucruri mai vesele... La capatul zilei, proverbele si adevarurile despre project management sunt cele care raman cu tine cel mai mult, ceea ce nu este deloc rau, ele sintetizand, lucrurile la care trebuie sa fim atenti cand ne aflam in fata unui proiect, intr-un mod simplu si usor de retinut, datorita umorului subtil, cateodata chiar negru, alteori autoironic, dar mai ales fiindca sunt atat de adevarate:

"If it wasn't for the 'last minute' nothing would get done."

"The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression."

"Powerful project managers don't solve problems, they get rid of them."

Si preferata mea: "Murphy was an optimist."

Posted by: Daniel Tulvan [Visitor] on 03/08/10 @ 00:23
Comment:

Un articol care mi s-a parut interesant a fost cel al lui Karl E. Wiegers: Standing on principle. Abordeaza o tematica interesanta: despre cum un dezvoltator sau manager de proiect nu ar trebui sa cedeze la princiipile care asigura un software de calitate, nici in fata clientilor, dar nici a managerului. Acestia ar putea avea pretentia sa se renunte la unele etape esentiale din crearea unui produs software, din motive de timp sau cost. A fi de acord cu un deadline nerealist este o dovada de iresponsabilitate. Sunt prezentate si cateva posibile solutii la aceste probleme si metode de a lua o decizie corecta si responsabila in relatia cu managerul sau clientii. Sunt mentionate si cele 5 dimensiuni ale unui proiect software: features, quality, cost, schedule, staff, interdependenta dintre ele si cum unele compromisuri pot afecta si alte aspecte. Ideea de baza poate fi sintetizata printr-un proverb gasit pe pagina Project Management Proverbs , si anume: "If you don't stand for something, you'll fall for anything."

Posted by: Adriana Buriuc [Visitor] on 03/08/10 @ 00:23
Comment:

"The first 90% of a project takes 90% of the time the last 10% takes the other 90%."
Cred ca oricine lucreaza la un proiect de dimensiuni mai mari isi da seama de acest lucru pana la urma. Ar fi bine sa tinem cont de el de cate ori estimam timpul pentru un proiect.

Alt proverb mai deosebit din "Project management proverbs" este "Murphy was an optimist", de care imi amintesc mereu, doar ca n-am stiut niciodata sa-l exprim intr-un mod atat de simplu si clar.

"Extreme Programming: A gentle introduction" explica o tehnica de improvement pentru software development pe 5 cai: comunicare, simplitate, feedback, respect si curaj. Se bazeaza pe o dezvoltare si o testare incrementala a codului si o interactiune mult mai stransa cu clientul.
Am mai citit cate ceva pe aceasta tema si pare sa fie o abordare tot mai folosita de dezvoltatorii de software.
Si mie mi se pare destul de eficienta, si am incercat sa o aplic atunci cand s-a putut.

Posted by: Raluca Grosan [Visitor] on 03/08/10 @ 00:48
Comment:

Pe scurt:

"The Ethics of Software Project Management" foarte interesant din punctul meu de vedere. Am intrat in contact cu cateva proiecte software de anvergura mai mare si pot spune ca etica este de multe ori lasata la urma in favoarea productivitatii. Merita citit articolul si uneori revizuita atitudinea.

"Extreme Programming: A gentle introduction" - Un proces de dezvoltare software dincolo de partea aceea atat de tehnica (specificatii,implementari,testari). Se pune accentul pe un stil de dezzvoltare in care clientul face parte din proces(nu este doar o variabila) si interactiunea dintre dezvoltatori, la randul ei este parte componenta a proiectului. Astfel totul devine mai fluid, mai natural, spre deosebire de vechile procese in care totul era cuantificat si abstractizat.

Posted by: Gheboianu Alexandru [Visitor] on 03/08/10 @ 13:06
Comment:

Primul articol pe care l-am citit a fost cel despre Extreme Programming. Din momentul in care am invatat aceasta tehinca la un anumit curs (PDSS), mi-am dorit sa ajung sa-l practic pentru ca se bazeaza foarte mult pe flexibilitate si inspiratie de moment. Acum chiar am ocazia sa lucrez in echipa pentru lucrarea de licenta adoptand aceasta tehnica de dezvoltare si, recunosc, ca are multe puncte pozitive. Asa cum spune si articolul, ideea de baza este teamwork 101%, scopul echipei fiind de a rezolva o sub-problema cat mai rapid si eficient. Organizarea si mangementul sunt independente pentru fiecare echipa, iar ritmul este alert (nu in sensul de 'stresant', ci pur si simplu nu se pierde vremea - mai bine lucrezi la capacitate maxima 4 ore si apoi iesi la un ceai, decat sa pierzi vremea prin meetinguri 8 ore). Da, legat de intalnirile intre echipe, alt aspect pozitiv este ca, intr-un anumit context in care am auzit aplicata metoda XP, aceste intalniri se tineau max 15min in picioare, asa incat nimeni sa nu aiba timp se se joace cu pixul sau cheile.

Al doilea articol (exista limita de caractere la comments ?) este despre pasiunea mea din copilarie - NASA (One Hundred Rules for NASA Project Managers ). Linkul de pe site nu mai este valabil, dar am gasit articolul imediat, si se refera la felul in care ar trebui sa se comporte fiecare persoana din ierarhia unui proiect - de la project manager pana la oamenii de stiinta si clienti. Articolul contine si pasaje hazlii, de ex., o scurta descriere a unui manager de proiect fiind "Vicious, despicable, or thoroughly disliked persons persons, gentlemen, and ladies can be
project managers[...]". La prima verdere ar parea o serie de idei aruncate haotic pe hartie, dar citite cu atentie, am impresia ca ascund o bogata experienta de munca, si nu orice munca, ci una la cel mai inalt nivel tehnologic, de responsabilitate maxima si risc ridicat. (Dar la NASA intotdeauna functioneaza motto-ul : "Cand nu mai exista solutii, ne intoarcem la studiourile din Hollywood", desi acum cred ca este mai ieftin in Bollywood).

Posted by: Alexandru Topirceanu [Visitor] on 03/08/10 @ 13:09
Comment:

Microsoft Office Project 2007
Screenshot

-realizeaza planuri de proiect, bugete, scenarii "what if", calendare ale resurselor, rapoarte pentru management -obtine controlul termenelor, duratelor si costurilor in proiecte
-integrare cu programe din gama Microsoft Office
-versiunea Professional include capabilitati colaborative de management de proiect cand este folosit impreuna cu Microsoft Office Project Server 2007

Elementool Help Desk
How it works

-permite crearea unui Customer Service
-existenta unui formular Contact Us
-toate mesajele primite de la clienti si trimise clientilor sunt stocate intr-o baza de date
-se pot urmari mesajele conform unui history
-generare de rapoarte

Posted by: Silviu Coca [Visitor] on 03/08/10 @ 20:31
Comment:

Servus,(asta in caz ca citeste cineva asta)

Eu am vrut sa stiu generalitati despre curs. Asa ca am citit de aici http://www.softwareprojects.org/software-project-management.htm si mi-a placut ca sunt chestii explicate asa numai potrivite pentru o minte ingusta. Si cum poti sa pricepi cele mai multe...exact...prin exemplu...si descrierea asta face exact asta. Ceea ce e beton pentru mine ca am regasit la capitorul despre requirements si risk management chestii care se intalnesc on a day by day basis at work. Deci e de bine. :D

BR, Remus

Posted by: Remus Gusa [Visitor] on 03/08/10 @ 20:45
Comment:

Ca si pe multi altii de aici, mi-au placut foarte mult acele proverbe management-ul proiectelor software. Majoritatea din ele transmit ceva care trebuie luat in seama. Facand acest lucru intr-o maniera hazlie si comica sunt relativ usor de tinut minte si cel mai important, de adus aminte atunci cand trebuie aplicate in practica. Unul din proverbe care mi s-a parut scurt si la obiect este acesta: "If you fail to plan you are planning to fail".

Un alt articol care mi-a facut cu ochiul este acela despre IDEAL (Initiating, Diagnostic, Establishing, Acting, Leveraging). Articolul descrie cei 5 pasi ai modelului de care trebuie tinut cont la implementarea unui proces de imbunatatire software foarte util unui manager de proiect de foarte mare anvergura. Acest model este, pana la urma, unul personalizat pentru fiecare companie in functie de particularitatile fiecaruia, de resurse, etc.

Posted by: Liviu Varga [Visitor] on 03/08/10 @ 20:53
Comment:

Buna seara ,

Eu am ales sa citesc articole referitoare la (Bussiness)Requirements, pentru ca de aici incepe dezvoltarea produsului software si ptr ca m-am confruntat de cateva ori cu situatii in care nu intelegeam ce vrea clientul.

Tips extrase din articolul "When Telepathy Won?t Do:Requirements Engineering Key Practices",Karl E. Wiegers

1.Exista ceea ce se numeste Requirements Engineering (domain) care se imparte in requirements development si requirements management
2.Req Development se refera la elicitation, analysis, specification, and verification
3.Key practices:
->Get Extensive User Involvement
->Focus on User Tasks
->Define Quality Attributes
->Prioritize Requirements
4.Referitor la membrii echipei care nu cred ca se merita sa investesti in better requirements processes , nu prea are rost sa incerci sa ii convingi, mai degraba tb schimbata cultura organizationala.

Al doilea articol("Automating Requirements Management",Karl E. Wiegers) sustine folosirea unui tool pentru Requirements Management.
Cateva motive care m-ar determina pe mine sa folosesc un tool:
-Store requirements attributes( ceea ce e destul d eimportant, dc ne gandim la varietatea de info pe care tb sa o retinem despre anumite cerinte)
-Track Status( cat la % din setul de requirements e implementat si verificat)
-Control access(permite accesul individual sau in grup )
-Communicate with stakeholders( anunta cand s-a facut un pas inainte spre dezv produsului)

In concluzie:
Daca exista deja o inginerie in spatele implementarii cerintelor produsului, use it ( cu bun simt) ca sa obtii satisfactia maxima a clientului.

Posted by: Cristiana DINEA [Visitor] on 03/08/10 @ 20:56
Comment:

La fel ca majoritatea,primul articol citit a fost 'Project Management Proverbs', unde sunt prezentate cu destul umor problemele din domeniu.
Dintre toate proverbele unul surprinde adevarata problema legata de estimare: The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times.
Alt articol citit este 'Ten Guaranteed Ways to Screw Up Any Project'. Mi se pare interesanta abordarea problemei prezentand contraexemple, mai ales in contextul dat. Practic in loc de a specifica pasii ce ar trebui urmariti pentru succes(abordarea clasica), se prezinta ce nu trebuie categoric facut pentru a evita esecul.
Interesant e si faptul ca majoritatea contraexemplelor au corespondent in articolul cu proverbe.

Posted by: Gabriel Lazar [Visitor] on 03/08/10 @ 21:20
Comment:

In primul rand, in ceea ce priveste articolul care prezinta proverbe, sunt cateva care pentru mine care mi-au atras atentia, pe care le voi accentua pentru a evidentia si mai mult anumite aspecte ale MPS. Daca 10 persoane estimeaza acelasi proiect, vor fi cel putin 11 rezultate diferite. Din mai multe interpretari ale unui mesaj, niciuna nu va fi adevarata. Un utilizator nu va raspunde niciodata la ceea ce te intereseaza. Cu cat planifici mai mult, vei sfarsi prin a planifica si mai mult.

In al doilea rand, as completa articolul referitor la etica MPS cu urmatorul fapt. Pentru ca o persoana sa aiba o idee despre MPS, trebuie sa fi trecut prin toate fazele de dezvoltare a unui produs software, trebuie sa fi facut organizarea unui proiect, sa vada de ce (nu) s-au adeverit anumite riscuri, sa fi scris documentatie, sa fi folosit tool-uri, sa fi pus in aplicatie diverse tehnici, selectandu-le pe acelea care se potrivesc cel mai bine contextului, sa fi facut analiza cerintelor, design, implementare, testare, mentenata, etc.

Posted by: Lucian Bosioc [Visitor] on 03/09/10 @ 00:32
Comment:

Buna,

Am scris in notepad si nu merge copy paste asa ca voi pune un link cu comentariul :

https://docs.google.com/Doc?docid=0ARDQ0IHxqClkZGQzbWc3d180OGhyNnB6amM2&hI=ro


Sper ca am scris bine, nu e tocmai placuta forma

Posted by: Nita Adrian [Visitor] on 03/09/10 @ 00:53
Comment:

Buna!

Am incercat sa gasesc ceva printre linkurile de pe site care sa dea o viziune aproape imediata asupra obstacolelor si problemelor cu care un software project manager s-ar putea confrunta intr-un viitor apropiat. Si cel mai pertinent link mi s-a parut cel de la Project Management in general, mai precis cel care trimite la un curs online, in care se explica intr-un limbaj mai simplificat ce are de facut un project manager si este si un mic video, destul de scurt ce-i drept, dar care este foarte bun ca sa ne puna in tema Learn Project Management In 15 Minutes. Persoana care a facut acest video, Bas de Baar, are si o carte scrisa pe aceasta tema, Surprise! Now You're a Project Manager.
Recomand cele doua clipuri plus ce se mai afla pe site ca si un ghid minimal spre Software Project Management.

Posted by: Kiss Csaba [Visitor] on 03/09/10 @ 15:52
Comment:

Si linkul la video :D

http://www.softwareprojects.org/project-management.htm

Posted by: Kiss Csaba [Visitor] on 03/09/10 @ 15:54
Comment:

-- Mesaj de la Mihai Coman --

Unul dintre articolele care mi s-au parut interesante inca de la prima rasfoire a
listei este "One Hundred Rules for NASA Project Managers"(poate din cauza
renumelui). Chiar daca link-ul de pe site nu este functional resursa este usor de
gasit, printr-o simpla cautare pe www.google.com. Este un articol concis care
prezinta sfaturi pentru manageri grupate pe categorii cum ar fi: comunicare, oameni,
rapoarte, planificare, evitarea esecurilor, etc.

Dintre cele 100 de reguli cel mai mult mi-au placut urmatoarele:
"Rule #62: Not using modern techniques, like computer systems, is a great mistake,
but forgetting that the computer simulates thinking is a still greater mistake."

"Rule #82: Wrong decisions made early can be recovered from. Right decisions made
late cannot correct them."

Un alt articol pe care am vrut sa il citesc era legat de calitate, pentru ca aceasta
ocupa un rol din ce in ce mai important in cadrul activitatii firmelor. Am ales
http://www.iso.org/iso/iso_9000_essentials.htm.

Posted by: Carmen [Member] on 03/09/10 @ 23:03
http://www.timsoft.ro
Comment:

Un tool destul de interesant pe care l-am gasit este Expesite. Este un organisational tool, pentru o varietate de tipuri de proiecte, nu doar software. Ceea ce mi s-a parut interesant este faptul ca este Internet based. Astfel este foarte avantajos pentru team-urile care lucreaza la distanta deoarece poate fi accesat si modificat de oriunde, oricand. Ajuta la o comunicare mai buna intre membri echipei, sharing de fisiere. Deasemenea asigura si o alternativa la cvs, tot online, ce ajuta la version tracking.
O prezentare sugestiva a programului puteti gasi la adresa http://www.expesite.com/homepage/demo_standalone.asp
Dezavantajul major: nu este free.


Project Management Proverbs sunt amuzante si au invataturi bune. Una care mi s-a parut foarte adevarata: What you don't know hurts you.

Foarte util cred ca este ProjectNet the project management information resource deoarece ofera informatii diverse incepand de la un template despre Managing Smaller Projects, pana la job-uri in domeniu.

Posted by: Catalina Dragu [Visitor] on 03/11/10 @ 17:09
Comment:

Va voi descrie cateva tehnici folosite in domeniul de software management despre care am auzit vorbindu-se foarte mult, despre care am citit si care sunt destul de folosite in ultima vreme. Sa spunem ca pot fi considerate un nou trend :)

1) : este o tehnica de time management folosita, in special, in proiecte software. Practic, developerul este propriul sau manager atunci cand vine vorba de estimarea timupului pe care il aloca fiecarui task. Timpul trebuie sa devina astfel, un atuu, nu un dusman pentru un software developer.

Un Pomodoro este o perioada de timp de 25 de minute, pe parcursul careia developerul se concentreaza doar asupra a ceea ce face, fara sa fie distras de altceva. Dupa fiecare Pomodoro se face pauza 5 minute. Dupa 4 Pomodoro-uri consecutive, se ia o pauza mai lunga.

Fiecare task pe care il are de indeplinit, trebuie estimat in Pomodoro-uri.

2)
Desi sunt foarte putini manageri software care lucreaza in mod agile, aceasta metoda este una dintre cele mai productive in domeniul managementului software.

Principalele roluri din acest proces:
1. the ?ScrumMaster? - cel care intretine procesul, in principal project managerul
2. the ?Product Owner? - reprezentant al stakeholders (cei care iau deciziile referitoare la produsul final)
3. the ?Team? - echipa software

Acestia au mai multe intalniri, printre care SCRUM Daily - un meeting zilnic, care are loc mereu la aceeasi ora, timp de 15 minute. Fiecare membru al echipei trebuie sa raspunda la 3 intrebari:
- Ce ai facut de ieri?
- Ce ai de gand sa faci azi?
- Ce probleme intampini?

Posted by: Andreea - Maria Badau [Visitor] on 03/12/10 @ 13:38
Comment:

Se pare ca nu au aparut titlurile la metodele descrise de mine anterior.

Primul: tehnica Pomodoro.
Al doilea: agile software management.

Posted by: Andreea - Maria Badau [Visitor] on 03/12/10 @ 13:40
Comment:

Unul dintre articolele care mi-a atras atentia a fost ?Are We There Yet?? de Johanna Rothman. Pana in acest moment am fost pus de nenumarate ori in situatia de a estima durata unui anumit task dar cu toate acestea de fiecare data cand dau o estimare nu sunt 100% sigur ca o voi putea respecta. Cu atat mai dificila consider ca este estimarea corecta a duratei unui proiect si a stadiului in care se afla acesta, in special deoarece aceste lucruri depind de o multitudine de factori ce pot varia: cerinte, costuri, bug-uri, mediul de lucru, oameni, etc. Mi-a placut acest articol deoarece prezinta o viziune unitara a ceea ce inseamna masurarea progresului unui proiect tinind cond de toti factorii ce pot influenta acest process.

Un alt articol care mi-a placut a fost ?Project Management Proverbs?. Desi prezentate intr-o maniera amuzanta lucrurile continute sunt cat se poate de utile si ar trebui cunoscute de catre orice project manager chiar daca ?There are no good project managers - only lucky ones? :)

Un weekend placut,
Andrei

Posted by: Andrei Chis [Visitor] on 03/13/10 @ 16:46
Comment:

Buna seara,

Din articolele specificate de dumneavoastra, cel mult mi-a atras atentia paginile diverselor tooluri, create pentru a ajuta in realizarea eficienta a responsabilitatilor project managerilor intrucat se investeste mult timp, si implicit fonduri in developarea si mentenanta acestor tooluri.

Daca unele sunt destul de simple, mundane, si cu feature-uri care pot fi numarate pe degete precum TimeTiger utilizat pentru time-tracking, sau Simply Project Office, care permite utilizatorilor sa-si monitorizeze si sa-si administreze responsabilitatile, aplicatiile software se pot complica, adaugand feature-uri de nepretuit precum Milestones, Kidasa Software. Acesta mi-a atras atentia in primul rand prin grafica user-friendly, care probabil il face mai usor de utilizat dar si prin numeroasele feature-uri specificate pe pagina web: o mare varietate de produse software Milestones, care permit pe langa planificare, developarea unor grafice, reporturi, prezentari.facute pentru imbunatatirea administrarii unui proiect.

Am dat peste multe articole dragute, diverse, si am ramas impresionata de varietatea larga si cantitatea bogata de informatii relevante si la subiect puse la dispozitia studentului, care cred ca trebuie sa va fi luat mult timp pentru a o cauta.

Posted by: Teodora Sandra Buda [Visitor] on 03/13/10 @ 22:26
Comment:

Hey,

Primul articol pe care l-am ales a fost cel cu proverbe despre managementul proiectelor.Mi se pare ca sunt pline de umor si de multe ori e nevoie de putin distractie ca admosfera sa fie mai destinsa.

Al doilea articol ar fi "A free on-line course on software project management",deoarece mi s-a parut interesat cum ne este prezentat pe pasi,cum trebuie sa abordam problematica.Imi place ca face trimite la multe videoclipuri,tutoriale de pe youtube,in care sunt prezentate teme de genu:"How To Improve Your Leadership Skills" si altele.E un articol care merita citit,deoarece fiind un curs poti invata multe lucruri utile.

O duminica frumoasa,

Corina

Posted by: Corina Ardelean [Visitor] on 03/14/10 @ 11:32
Comment:

O resursa care dupa parerea mea ar fi practica este cea de la http://www.projectconnections.com/. Aici la sectiunea Burning Questions on Project Management, care desi este o resursa rezervata pt clientii "premium", din sampelul pe care il ofera pare sa ofere raspunsul pt o buna parte din intrebarile pe care un angajat in functia de Project Manager le are. La inceput, in deosebi, cred ca este foarte util sa ai pe cine cu mai multa experienta la care sa poti apela cand dai de un impas.

Posted by: Cuc Dan Mihai [Visitor] on 03/14/10 @ 14:40
http://www.projectconnections.com/knowhow/burning-questions/index.html
Comment:



Buna tuturor,

In primul rand consider ca e esential pentru toti cei care doresc o cariera
in domeniul IT contactul cu PRINCE2 si ITIL, training-ul, iar apoi sustinerea
examenelor.

http://www.ogc.gov.uk/methods_prince_2.asp PRINCE2 este o metodologie pentru
Project Management care include initierea proiectului, scope management, time management, quality, procurement, communication, risk management.
ITIL (Information Technology Infrastructure Library) este un framework care defineste standarde pentru suport IT si delivery.

O alta resursa care mi-a atras atentia este: http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html
COnstructive COst MOdel II este folosit pentru estimarea costurilor, efortului, si planificarea activitatii de dezvoltare software o parte extrem de importanta in Managementul de Proiecte.
Pentru cei interesati, exista o versiune Demo a programului, care e free.
http://www.softstarsystems.com/demo.htm

Va doresc o seara frumoasa,
Raul Pop

Posted by: Pop Raul [Visitor] on 03/14/10 @ 19:31
http://raul-photo.blogspot.com/
Comment:

Hey everyone,

Am avut probleme cu postarea comentariului (cred ca era prea lung), asa ca l-am aruncat aici: http://tinypaste.com/5143b

Seara faina:)
Anca

Posted by: Anca Jurca [Visitor] on 03/14/10 @ 23:45
Comment:

Primul articol ales de mine este Program Management --
Turning Many Projects into Few Priorities with TOC
in care am aflat ca a incepe un proiect in paralel cu altele nu este cea mai buna solutie, ba chiar mai mult timpul de realizare al proiectului poate sa se multiplice. De aceea autorul ne sfatuieste sa prioritizam lucrurile si sa nu le grabim.

Al doilea articol este cel cu proverbele, deoarece am observat ca a trezit interesul multor colegi de-ai mei. Dintre cele trei sectiuni cea mai simpatica este partea a 3-a in care suntem avertizati ca daca un lucru poate sa mearga prost va merge in cel mai prost mod posibil.


Va urez o seara placuta,

Iuliana Olaru

Posted by: Iuliana Olaru [Visitor] on 03/15/10 @ 00:19
Comment:

Si cel mai pertinent link mi s-a parut cel de la Project Management in general, mai precis cel care trimite la un curs online, in care se explica intr-un limbaj mai simplificat mcsa ce are de facut un project manager si este si un mic video, destul de scurt ce-i drept, dar care este foarte bun ca sa ne puna in tema Learn Project Management In 15 Minutes. Persoana care a facut acest video, Bas de Baar, are si o carte scrisa pe aceasta tema, Surprise! Now You're a Project Manager.

Posted by: mcsa [Visitor] on 06/01/10 @ 14:33
http://www.mcsatrainingclasses.com

Comments are closed for this post.


Carmen Holotescu
Director Timsoft
Activitati curente
Despre acest blog

marker  Sindicare
marker  Microblog

cirip.ro - microblogging

marker  BlogRoll
  • Colectia de bloguri/RSS romanesti
  • Bloguri educationale romanesti
  • Bloguri business romanesti
  • My favourite eLearning blogs
  • Toate RSS urmarite
  • All RSS I read
  • marker  Blogs Tools
    marker  Powered by