Projektijuhtimine

  • Allar 14 a

    Küsimus neile kes töötavad veebifirmas või lausa juhivad seda:
    kuidas toimub teil projektijuhtimine ehk siis kuidas edastab projektijuht projekti nõudmised, eesmärgi etc. pasa kliendile, progejale ja kujundajale?

    Plaanis kirjutada sellest diplomitöö, uurin erinevaid mooduseid, niiet kel huvi veidi aidata, siis vastake või kontaktige allar ätt viik.ee. Aitäh!
    PS. mingit infot ma ei publitseeri või kellegi nime asjaga ei seo.

    03. oktoober 2006 - 15:08:17 · Otselink

  • mis on sinujaoks keksmine või suurem ettevõte?

    03. oktoober 2006 - 15:43:55 · Otselink

  • Allar 14 a

    see ei ome tähtsust tegelikult, peaasi, et on olemas mingi süsteem :)

    03. oktoober 2006 - 15:55:58 · Otselink

  • noh keskmisest ja suuremas veebifirmas ja sellelaadses ettevõttest eesti mõttes sa ei leia muud erilist süsteemi peale pakkumispõhja mis igas firmas erinev :) ja ülejäänud juhtimine käib kuidas jumal juhatab e-maili vahendusel

    tarkvarafirmas ehk leiad mingi kindlama protsessi kajastuse .Vaata just ISO sertifikaatidega ettevõtteid neil peavad protsessid kirjeldatud olema.

    03. oktoober 2006 - 17:12:21 · Otselink

  • ISO sertifikat on muidugi selline asi, mis on paber paberi pärast, reaalset tööprotsessi see ei kajasta. Külla aga jah dokumentatsiooni ja selle korashoidu ... Mingi teatava aja tagant kontrollitakse ju firmat : )

    Aga muidu suuremate veebide puhul koostatakse projekt (dokument paberil), mis edastatakse nii kliendile, kui pärast lepingu sõlmimist ka kõigile tööga seotud osapooltele. Projektijuhti edasine ülesanne on kontrollida selle projekti täitmist ja olla puhver kliendi ja töö teostajate vahel. See tähendab tähtaegade kontrollimist, meeskonna koosolekuid ja ajurünnakuid, jooksvate probleemide lahendamise organiseerimist ja projekti eelarve jälgimist. Selline masinavärk läheb aga reaalselt käima tõesti suurte projektide puhul, pisemate nn. tava veebide puhul tsit. vaalast : "juhtimine käib kuidas jumal juhatab" ...

    03. oktoober 2006 - 18:41:10 · Otselink

  • wuzz 14 a

    ISO ei ole ainult paberi pärast :) See tähendab et tööprotsess üleüldse eksisteerib.

    03. oktoober 2006 - 18:51:14 · Otselink

  • Ei nuh :) sellega ma olen nõus, aga point oli, et reaalset töö protsessi see ei kajasta ... Aga selles mõttes, et firma usaldusväärsust näitab ta muidugi ja eks see tema mõte olegi. Aga mitte antud teema kontekstis.

    03. oktoober 2006 - 19:36:02 · Otselink

  • c5ef2 14 a

    Tavaline väike firma võiks välja näha selline:

    1. Müügimees, vahest ka projektijuht, müüb kellelegi midagi utoopiliste tähtaegadega ja odava hinnaga projekti maha. Müüakse suuresti seda mida on, mitte seda mida klient tahaks või vajaks.
    2. Hinnapakkumine pannakse kokku mingist üldisest templatest (vahest on jäänud sisse veel eelmise firma nimi :)
    3. Leping allkirjastatud, läheb lahti suuremaks rapsimiseks, kuna tähtajad on lühikesed, siis arendajad panevad tugevalt ületunde, sest asi on ju vaja valmis saada! Enamasti ei viitsi projekti alguses keegi väga teha ka midagi.
    4. Tähtajad lähevad üle, projektijuht slapib rohkem progejaid ja muid töötegijaid ja ei saa aru, kuidas see valmis ei saa juba.
    5. Mingi vigane käkk saab valmis ja antakse kliendile üle. Klient saab midagi, mis talle ei meeldi.
    6. Projektijuht käib lehvitab lepingut, näitab et nii oli kirjas ja nõuab pappi!

    Kliendil esimene odav kogemus käes, tulevikus tõenäoliselt valib mõne mõistlikuma firma ja on nõus ehk nats rohkem maksma.

    ISO tähendab enamasti hästi palju dokumenteerimist. Räige bürokraatia ja uimerdamine. Selle asemel, et tööd teha ja tulemusi saada, siis need tüübid ainult analüüsivad ja dokumenteerivad kõike.

    03. oktoober 2006 - 19:51:42 · Otselink

  • Allar 14 a

    mõni võiks kirjutada kuidas see asi IDEAALIS välja näeb ;)

    aga tegelikkuse kohta ma ilmselt korraldan mõne küsitluse vastavate firmade seas.

    03. oktoober 2006 - 19:57:31 · Otselink

  • noh selline analüüs tuleb kliendile lõppkokkuvõtteks kasuks nagu sa ise just ilmekalt esitlesid. Iseasi kas seda kõike alati vaja on :)

    http://readyset.tigris.org/ on yks hea näide projektitdokumentatsioonist, sealt võid valida just endale vajalikud vormid ning nendega edaspidi iseseisvalt majandada. Saad endale koostada erineva suurusega projektide jaoks ideaalse dokumentatsiooni. Samas ma kardan, et sa ei viitsi seda bürokraatiat tõesti läbi teha, sest Eestis ei ole ka keskmistel firmadel selliseid projekte mis sellist träkkimist otseselt nõuks .) kuigi ilus ju oleks.

    Hea ressurss on ka microsofti veebileht kus tutuvustatakse microsofti enda projektihaldust ja kasutusolevaid patterne.

    erinevate firmade kohta saaad vist ainult siis teada, kui erinevatest kohtadest küsid

    minul on enamasti käinud asjad seliselt:

    1. kliendi vajaduste kaardistamine: tekstidokumendina ja intervjuuna

    2. selle põhjal spetsifikatsioon: tekstidok mis on lpingu lisa ja kohe ülesandekirjelduseks arendajale, keksmise projekti puhul mahub see enamasti ühte meili või tiimikoosolekusse. Ei ole seda ajanud tehnilieseks ja UML formaati , sest klient ei saa sellest ilma spetsialisti palkamiseta sittagi aru ja on pärast unhäpi, kui ma näitan kuidas asjad kokku lepiti. Tähtis on ju ikkagi kliendi rahulolu ja kasutatav tarkvara.

    3. kujundaja kujundab , kohtub kliendiga teeb erinevad kavandid vaidleb kollase kollaseks: selle resultaadiks veebi puhul on kavandid erinevatest lehe funktsionaalsustest (pealeht, alamleht, otsing, tagasiside jne oleneb palju erinevaid asju on).

    4. Kavand läbi vaieldud lendab see meiliga arendajale, hakib hmliks, genereeritakse väljundid ja vajalikud sisendid aplikatsiooniks. Vahepeal sada kommentaari ja tihti vaevub klient kommenteerima alles hetkel, kui kõik valmis ja vaja juba ringi teha. Läbi sellise onamise jõutakse lõpuks tulemuseni mida saab kasutada ja testima hakata. Testitakse ja muudetakse kuni okei.

    5. avamine, arve, tasu jne

    Ideepoolest võiks asi käia palju karmimalt:

    1. analüüs: intervjuud uscased UML ja arve analüüi eest
    2. leping, lisad, ettemaks (kujundusega sama protsess)
    3. tehakse rangelt analüüsi järgi, ennem arve tasumist midagi ei muudeta
    4. arve selga ja edasine hoolduse või uue arendusna punktist 1

    aga keskmiste projektide juures see sageli overkill, hea resultaat ühe eelarve raames on olulisem ja mingil määral alati erinev, kui algselt kokku lepiti. Suuresti seetõttu, et keskmisi asju on valdav osa ja kliet ei ole valmis selle eest lisa maksma ta pigem riskib feilida, kui keskmisse asja overkilli investida ja lõppeks ikka felida :)

    03. oktoober 2006 - 20:11:35 · Otselink

  • Allar 14 a

    vaalas võttis asja suhtkoht kokku :)

    on veel mõni kes julgeb rääkida kuidas temal asjad käivad?
    või kuidas peaksid käima ;)

    03. oktoober 2006 - 21:40:59 · Otselink

  • c5ef2 14 a

    Ma küll vaidleks vaalaskala teise osa 3 punktile vastu. Tegelikult kogu tema ideelisusele :)

    Natuke sellest, kuidas meil softi arendus praegusel hektel toimub, mille käigus me kasutame ära üsna palju XP (extreme programming) sarnast lähenemist.

    Kogu protsess toimub iteratsioonides, mille pikkus on 1 nädal. Iga iteratsioon algab iteratsiooni planeerimisega, mille käigus täpsustatakse kliendiga kohtudes nõudeid ja määratakse töö järgmiseks nädalaks koos täpsustatud ajahinnangutega.

    Ideaalis võiks projekti käigus mitu reliisi toimuda üsna väikeste ajavahemike tagant (nt 1 kuu). Selle käigus on võimalik näha, kuidas antud tarkvara reaalses elus töötab ja mida võiks muuta jne. Ehk siis on võimalik tagasisidet kogu projekti käigus saada.

    Nõuded pannakse kirja user storydena, mille on võimalik ühe lausega kokku võtta. Kui arendajal on küsimusi või tahab täpsustada, siis on tal võimalik see user story teisele poolele enda jaoks kirja panna. Storyd pannakse kirja postit lipikutele, mis omakorda on suurel (A2) suurusel paberil ja asub seinal kõigile pidevalt nähtavas kohas.

    Storyde eest vastutajad (ei tähenda ilmtingimata tegijat) määratakse iteratsiooni planeerimisel ning tema annab sellele sellele hinnangu.

    Kuna storyd on mahult üsna väikesed (max 2-3 päeva arendust), siis nende hindamine on ka üsna tõepärane. See omakorda tekitab kliendis usaldust ja rahulolu, kuna ta teab, kuidas projektil reaalselt läheb. Võimalik on ka anda esialgne hinnang olemasolevatele storydele, mille järgi on võimalik umbes(!) öelda palju see projekt aega võtab ja raha kulutab.

    Igal hommikul on 5-15 minutiline standup meeting, mille käigus räägitakse mis juhtus eile ja millega täna tegeletakse. See on hea võimalus klienti kogu aeg kursis hoida juhul kui peaks tekkima töö käigus mingeid viivitusi. Ja seega ei tule ka üllatusi, et nüüd keegi arendajatest tegeles kogu nädala mingi hoopis muu probleemiga, mitte sellega millega oleks pidanud.

    Samuti on teistel teami liikmetel selle käigus hea võimalus teada saada mis seisus üks või teine asi on. Eriti kui mitu erinevat storyt teineteisest sõltuvad.

    Eelnevalt väga palju ei analüüsita, kui siis ainult nii palju, et tehtav story tehtud saaks. Arenduse käigus ei mõelda oluliselt ka sellele, et "äkki läheb homme seda feature't vaja". Ja minu arvates ei olegi keskmisi ja suuri projekte täpselt ette näha. Alati selgub palju alles tegemise käigus.

    Lisaks on väga oluline see, et klient ei tea kunagi väga täpselt mida ta tahab saada. Projekti käigus tuleb nii arendajatel kui ka kliendil palju häid mõtteid, mida võiks rakendada ja muudavad tarkvara palju paremaks kui alguses planeeriti.

    Dokumenteeritakse ainult seda, mis on vajalik (arendajatele kui ka kliendile ja teistele osapooltele), mitte ei kirjutata dokumentatsiooni dokumentatsiooni pärast. Teiseks on üleliigse dokumentatsiooni uptodate hoidmine ka paras peavalu.

    Testimine toimub kogu projekti käigus, mitte ei ole üks osa projekti lõpus. Sealjuures on nii testijad, kes üritavad leida võimalikke vigu ja automaatsed testid, mis teevad testimise kiireks ja lihtsaks. Leitud vead tuleks ka kirjeldada automaatsete testidega, mis välistavad selle vea uuesti tekkimise. Kui teste on võimalikult palju, siis on ka võimalik muudatusi teha ja üsna kindel olla, et midagi katki ei teinud muutustega.

    See töötab edukalt majasiseste projektide puhul.
    Suurema osa väliste klientide jaoks on see ilmselt vähemalt esialgu üsna vastuvõetamatu. Peamiselt sellepärast, et on harjutud palju dokumentatsiooni (näitab, et teostaja on tegija), täpseid tähtaegu (mis suurelt jaolt üle lähevad või siis rapsitakse kõvasti) ja arve suurust teada saama.

    Kuigi ma loodan, et minu kirjeldatud lähenemine levib rohkem ja tekib suurem rahulolu nii tellija kui teostaja pool - klient saab tarkvara mida ta tahtis, mis töötab ja aitab tema ärile kaasa ning teostaja on rahul, sest rahulolev klient on talle pidev sissetuleku allikas ja tööandja.

    03. oktoober 2006 - 22:43:54 · Otselink

  • "3. kujundaja kujundab , kohtub kliendiga teeb erinevad kavandid vaidleb kollase kollaseks."

    Auch. mm kujundaja kujundab. hea kujundaja ei oska vaielda, nii et sitt juhus kujundaja kliendiga vaidlema panna ...

    03. oktoober 2006 - 22:48:33 · Otselink

  • c5ef2 14 a

    Ahjaa, mis mul mainimata jäi on see, et väga oluline on, et projekti käigus oleks võimalik kliendil arendajatega/disaineritega ja vastupidi suhelda!
    Suhtlemine on suhtkoht kogu asja alus, kui see puudub, siis ei ole loota ka väga häid tulemusi.

    Seega frizuurikas, hea kujundaja peab ka oskama oma arvamust või nägemust kliendile selgitada ja vajadusel ka asjad selgeks vaielda.

    See ei aita, kui ta õhtul kodus vannub, et klient on loll ja ei saa aru kui hea tegija ta ikka on ja tema ideed kliendile kohe ei sobi ja arusaadavad pole :)

    Minu arust ei saa olla hea progeja inimene, kes üksi nurgas istub ja analüüsi põhjal midagi valmis progeb ning kes teistega peaaegu üldse ei suhtle (kui siis maili teel sunniviisiliselt).

    03. oktoober 2006 - 23:02:28 · Otselink

  • c5ef2, üldiselt on ideaal ilus, aga kogu igapäevane asi võiks toimuda läbi intraneti ja kord nädalas 1/2-2 tunnisest tiimi koosolekust piisaks. Dokumenteerimise osas siis esmalt tuleb ikkagi dokumenteerida eesmärgid, mida saavutada, kliendi ja teostaja poolt, see, et antud eesmärke saab ka paremini ja teisiti saavutada, selgub sageli töö käigus, aga tuleb välistada see, et hakatakse saavutama midagi, mida algselt ülepea plaanis polnud, kuigi kui kliendil tekib idee (või ise välja pakud) ja see vastab vajadusele, saab selle alati juurde lisada ... Aga muidu sinu skeem töötab ilusti ..

    03. oktoober 2006 - 23:06:37 · Otselink

  • c5ef2 , kui kujundajale makstakse selle eest, et ta kliendiga vahutab 2-3h selle asemel, et tööd teha, miks mitte ... üldiselt on see ju ikkagi ajaraisk ...

    03. oktoober 2006 - 23:09:30 · Otselink

  • c5ef2 14 a

    "kogu igapäevane asi võiks toimuda läbi intraneti ja kord nädalas 1/2-2 tunnisest tiimi koosolekust piisaks"

    5-15 minutit ei tapa kedagi (sama kaua kestab üks kohvipaus). Lisaks 20-30 meetrit end liigutada ei tee ka haiget. Sõltub muidugi teami suurusest ja kuidas team asub - 50 inimest 10 eri riigist kokku saada iga hommik on keeruline.

    "et ta kliendiga vahutab 2-3h"

    Kui ta iga päev nii palju pläkutab maast ja ilmast siis on teine asi, aga kui aegajalt tööalaselt seda teeb, siis ma ei näe probleemi :)

    03. oktoober 2006 - 23:21:54 · Otselink

  • aja planeerimisega on siin midagi natuke nihkes. aeg-ajalt pläkutab disainer kliendiga 2-3h, aeg-ajalt progeja 2-3h projektijuht peaks rohkem pläkutama ... seega juttu saab palu ... iga hommik on veerand tunnine koosolek (pärast seda kohvipaus muidugi) ... et me korrektsed oleks, siis kleebime tahvlie sedeleid ka ... nüüd eeldame, et meil ongi projektiga tegelemas 50 inimest, siis kuidas see komunikatsioon toimub ? ... ma arvan, et kui nii suuremat projekti hakata juhtima on probleemid kiired tulema : O)

    03. oktoober 2006 - 23:30:39 · Otselink

  • noh ärge nyyd sita asja pärast tülli minge :D

    XP on sellesuhtes omalaadne asi, et seda võib teha nii nagu tiimile parasjagu sobib ja samas XP ka igale poole eriti ei sobi kuna klient ei pruugi sammu pidada ja kogu protsess sööb ikka parajalt närve :). Samas , kui pappi on ja eelarve kummist , head partnerid ja arendajad :) sobib nagu rusikas teadagi kuhu.

    Lihtsalt mul ei ole selliseid juhuseid ja nii suuri kliente kes seda pidevat ülesande muutmis ja paremuse poole voolamist valmis finantseerima oleks. Kõigil eelarve ja kindel siht silme ees, tähtaeg lööb jalaga perse kliendile ja arendajale ja resultaat on kokku lepitud. Seda puhtalt veebiarenduse pinnalt, kui väike kala suues tiigis ja eks see olegi vist väikeste tegijate probleem rohkem.

    "Ma küll vaidleks vaalaskala teise osa 3 punktile vastu. Tegelikult kogu tema ideelisusele :) "

    see ei olegi XP ja sellepärast ka teise ideega, see on paljude keskmiste tegijate reaalsus ja üks võimalus oma asjad edukalt ilma miinusesse jäämata lõpetada.

    Mis puutub sellesse, et kujundaja suhleb, siis siin ma mõtlesin seda asja rohkem piltlikult kuna ma ise kujundamisega ei tegele ja kujundus mida vaja realiseerida tellitakse alati mujalt

    03. oktoober 2006 - 23:50:16 · Otselink

  • Ma olen ka frizuurikaga nõus. Disaineri ega progeja asi ei ole kliendiga suhelda, selleks on projektijuht. Kui projektijuht ei suuda infot piisavalt hästi mõlema poole vahel jagada, ega mõlemale poolele sobivaid otsuseid vastu võtta, ei sobi ta oma kohale.

    Kõige rõvedamad on sellised projektijuhid kes iga väikse sita pärast disaineri ja progeja aega raiskavad ja kokkuvõttes projekti üle aja ise ajavad.

    04. oktoober 2006 - 16:45:43 · Otselink