Vizualus projektų valdymas

Projektų valdymas yra tokia kančia, kad net buriamės į asociacijas, kur galėtume išsipasakoti savo problemas. Viena iš problemų vadinasi “kaip viską suvaldyti?”. O dar geriau, kaip padaryti,kad viskas būtų vizualiai skaidriai pateikta. Taigi į akis papuolė straipsnis, kur projektų vadovai bando šią įdėją realizuoti. Stipriai nudžiugino, kad yra sprendimo elementai, o nuliūdino, kad vėl nebandyta įvardinti problemas, kurios yra sprendžiamos.

Yra trys skirtingo suinteresuotumo žmonių grupės, kurie turi didelį poreikį vizualinei informacijai.

Tai projekto savininkas, užsakovas, kuriam idomi tik bendrinė projekto informacija. Todėl labai gudrios vizualizacijos lyg ir nereikalauja. O koks šių suinteresuotų žmonių tikslas? Užbaigti projektą laiku. Taigi projekto vykdymo metu juos domina, kiek projekto yra jau užbaigta, ir kokia tikimybė, kad pavėluosime, ir kiek pavėluosime. Į šiuos klausimus atsako CCPM, kaip ir duoda pasiūlymus vizualizacijai. Bet čia galime priskirti ir projektų portfelio vadovą, kuriam be bendrinės projektų informacijos reikia dar ir detalios išteklių apkrautumo ataskaitos.  Lyg ir ne problema susirasti variantą, kuris labiau patiks.

Toliau yra projektų vadovai. Deja, kol kas jiems nieko geresnio už GANTT nėra sugalvota. Programinės įrangos vizualiniam valdymui yra prikurta tuntai. Tiek mokamos, nemokamos, ar Excel pagrindu. Kaip ir nieko naujo.

Ir lieka darbuotojai, kuriems visi tie GANTT yra neįdomūs, jiems labiausiai patinka Scrum. Kaip sako projektų komandos narių patirtis, ”vaikščioti vandens paviršiumi ir kurti IT produktą pagal specifikaciją – abu dalykai įmandomi, jei objektas užšaldytas“. O Scrum tokią galimybę suteikia. Scrum duoda įdėjų, kaip geriau pateikti projekto informaciją projekto komandos nariams. Tiesaa visa informacija, kuri reikalinga projekto nariams, yra užduotys.

Atrodo aš pakartojau viską, kas buvo paminėta „Visual Project Management“ straipsnyje. O kas liko nepaminėta? Visų pirma, tai tik skirtingos įdėjos, nesujungtos į vieną visumą. Juk projekto vadovui reikia bendrauti tiek su užsakovu, tiek su komandos nariais, ir kiekvienas turįs savo tikslus, ir kiekvienam informacija vis pateik skirtingai, po to surink informaciją, neretai ją reikia dar ir išversti, kad galėtum pasinaudoti. Šiam momentui man neteko išvysti programinės įrangos, kuri padėtų projekto vadovui sistemingai dirbti, yra tik skirtingi šios sistemos komponentai. Beje, kartais visai neblogai realizuoti.

Ir štai ateiname prie pagrindinio klausimo: net jeigu viską sujugtume į vieną sistemą, ar tai veiktų? Prieš atsakydami, prisiminkime, kad užsakovui neįdomu, kaip jūs projektą vykdote, jam įdomu tik – kada ir už kiek. Projekto vadovui įdomu, kaip vykdome projektą, ir kad visi komandos nariai turėtų darbo, o komandos nariams, neįdomu, kaip sekasi projektas, svarbiausia kaip nors atlikti savo darbus. Kaip matote, nėra bendro tikslo, ir todėl kiekvienas rūpinasi tik savim. Dėl šios priežasties yra tik sistemos komponentai. Tada projekto vadovui nieko kito nebelieka, tik pasiguosti savo ratelyje.

Norėtųsi surasti programinę įrangą, kuri apjungtų projektų portfelio valdymą, projektų valdymą su CCPM ir užduočių valdymą, ir kuri realiai veiktų. O gal aš tiesiog nerandu, ir skaitytojai gali pasidalinti savo atradimais?

komentarų yra lygiai 33

  1. Manau, kad teiginiai “užsakovui neįdomu, kaip jūs projektą vykdote, jam įdomu tik – kada ir už kiek” ir “o komandos nariams, neįdomu, kaip sekasi projektas, svarbiausia kaip nors atlikti savo darbus” iš esmės yra klaidingi. Bet ant tiek plačiai naudojami Lietuvoje, kad net yra pasieke “aksiomų” lygį. Tose šalyse, kur yra normalios IT praktikos patirties, užsakovai IT pirkimams diegiasi CMMI standartus, nes jiems rūpi kaip bus vykdomas projektas, o komandos eina peopleware’ą, nes nori būti produktyvios. O čia pas mus, kiek man teko matyti, sėkmingi projektai (visomis prasmėmis) būna tie, kurių dalyviai savo veiksmais “stengiasi” paneigti šiuos teiginius.
    O dėl vientiso soft’o kuris rodytų visus tuos dalykus turbūt nerasit. Todėl, kad jeigu kas nors imtusi ir tai pagamintų, tai būtų monstras, kuris vargu ar apsimokėtų. Kažkada prieš kokius 6m. IBM’as įsigijo kompaniją ir jos produktą pristatė kaip Rational Portfolio Manager. Joje buvo beveik viskas, ką išrašėt išskyrus gal padorų CCPM. Na bet tai būtų galėje pridaryti, juk yra toks plug-in’as net Microsoft Project’ui. Tačiau papūtė agile vėjai ir metė IBM’as tą produktą per langą. Ir sukūrė Rational Team Concert – totalus agile’as developer’iams. Šiek tiek (lyginant su RPM) galimybių projektų vadovams ir jokio (kiek pamenu) išreikšto resource management’o. O ir iš principo, kaip derinasi agile ir resource management’as? Na tais atvejais, kai nėra WBS’o? Žodžiu jausmas toks, kad developer’iai kaifuoja nuo eilinio tools’o, o projektų vadovai organizuojasi excel’iukus, kad galėtų po to suvedinėti info į CEO business inteligence sistemas. :)

    • CMMI yra senai tapes, kaip ISO. Visi stengiasi ji tureti ir niekas nenaudoti. Lietuvoje buvo viena sertifikuota CMM Level 2 ir kelios imones kurios teige, kad atitinka. Bet realybeje, net trecdalio nenaudojo. Indai isidiegia CMM 3 lygi per pusmeti. O kai suzinai kokiu budu, tai supranti, kad tarp idejos ir realizacijos nera jokio rysio. Gaila, kad bet kuri gera ideja suvedama iki apsurdo.
      Nu RUP buvo gerai, pries kokius 15 metu. Ir labai jau buvo orentuotas i softa gamyba, bet visiskai neturejo resource management, kaip cia ir gerai pastebeta. Beje beveik visos sistemos labai silpnai organizuoja task management su resource management. Pagrindine priezastis – darbuotojai nemegsta grieztos kontroles ir padaro viska, kad irodytu, kad esi neteisus.
      Todel islieka klausimas, jeigu zmoniu santykiuose yra konfliktas, ar gali kokia nors metodika, PI, ar sistema ji ispresti? :)

      • Bet aš negirdėjau nei vieno užsakovo Lietuvoje, kuris būtų įsidiegęs procesą sertifikuotą nors CMM L2 IT pirkimams valdyti.
        O RUP, RPM ir RTC yra visiškai skirtingi ir tarpusavyje tiesiogiai nesusije dalykai – nepainiokit.
        O dėl konfliktų… tai aš būčiau irgi laimingas jeigu galėčiau daryt ką noriu, niekam nereiktų atsiskaitinėti ir dar padorią algą mokėtų. Žodžiu būčiau gerai apmokamas menininkas. Deja, bet tokių gamtoje nebūna: arba neturi garantuotų pajamų ir esi menininkas, arba gauni algą ir turi atsiskaityti. Laikas tai suprasti ir IT projektų vykdytojams.

        • :) kur ta supratima surasti?

        • Va čia ir yra TIKRO projekto vadovo darbas – organizuoti komunikavimą komandoje ir su projekto dalininkais taip, kad tokių – metodinių ar konfliktinių – klausimų (beveik) nekiltų. Ir jeigu projekto vadovas negali tokio supratimo nunešti iki kiekvieno komandos nario – vadinasi jam reikia dar daug daug mokytis ir tobulėti. :)

        • Visiskai teisingai!!! Tik deja geru PV nera simtai. Ir klonuoti nesigauna, kaip galima daryti su softu. Va ir norisi surasti irankius kurie neleistu klysti tipo POKE-YOKE pagal LEAN. Ideja gal ir fix, bet naujokai mazai nesamoniu darytu.

        • Neneigsiu, kad įrankiai gali padėti suformuoti tam tikrus bazinius įgūdžius, bet… čia kaip TPS’e – klonuoti reikia ne įrankius ar metodus, o kultūrą. Kitaip norimo efekto vis tiek nepasieksit.
          O geri PV klonuojami sodinant juos dirbti PV asistentais šalia gerų PV. Ten ir įrankius pamaigo ir pamato, kaip ką reikia daryti. Nu jeigu būna labai protingas, tai dar pamato ir ko nereikia daryti – tokie greit išauga “asistento marškinėlius” :)

  2. Laurynas

    Poste aprasyta dalyka galima labai nesunkiai pritaikti konkreciai imonei, naudojant OFBiz arba Opentaps.
    Vis tiek visi projektus vykdo/valdo skirtingai, todel nebus visiems tinkamo softo anyway. Reikalinga paimti lankstu frameworka ir ji pritaikyti (efektyviai, nes frameworkas- efektyvus) konkreciam klientui. Tada TAI veiks. Kitaip- turbut, kad neveiks:)

    • OFBiz arba Opentaps tai daugiau ERP sistemos, o ne projektu portfelio valdymo sistemos :( . Beje Opentaps truputi neteisingai atvaizduojamas po IE9 :)
      O del framework’o tai jus esate ir teisus, ir neteisus. Frameworkas, kaip universalus dalykas vienu metu tinka viskam ir konkreciai niekam. Tai reiskia, kad teoriskai galima pritaikyti, o va konkreciu atveju gali ir nesigauti. Va kodel as ziuriu jau i pritaikymus, nes tada nors zinai, kur galima panaudoti, o kur ne.

      • Laurynas

        Ir OFBiz, ir Opentaps yra pakankamai lengvai pritaikomi (zr., pvz., Honeywell case study @ opentaps.org), todel konkreciu atveju reikalingas kvalifikuotas zmogus ar komanda, kuri TAI igyvendintu. Kaip ir bet kuriame biznyje;)
        Jau esami pritaikymai bus realizuoti kazkam konkreciai, todel netiks musu klientui arba bus realizuoti visiems- ir todel taip pat netiks musu klientui.
        Frameworkas ir yra padarytas tam, kad ji butu galima lengvai pritaikyti tam, kam reikia:)
        O del IE9… Su skaitliukais Opentaps atvaizduos dar prasciau:)) No offense;)

        • Va, va, tai neveikia po IE9, tai dar ka nors kreivai rodo, ir tada klientas pasiulo susirinkti savo zaislus ir eiti kur nors kitur savo mandruma rodyti. O veliau visiems aiskina, kad siuloma sistema neveikia. Su visa pagarba open sourciniams projektams, noretusi isbaigtumo su monkey proof and friendly UI. :)

  3. Laurynas

    @ audrius del IE9: IE9 siuo metu yra tik 0.59% vartotoju. Gal dar po Lynx pradesim rodyma tikrinti?:))

    • Laurynas

      @ audrius: ir jeigu tamstai sitas opensource neatrodo pakankamai rimtas, kai ji naudoja Toyota, DKNY, Honeywell, etc., tai jau nezinau, ko tamsta norite, turbut Jusu reikalavimai daug-daug aukstesni, nei siu kompaniju…
      Sekmes diskusijose.

      • Kazkaip niekur nerandu, kad as nurodziau, kad butent SITAS opensource atrodo nepakankamai rimtas. Nes jeigu prisiminti, kad Linux yra opensource ir kiek, ir kokiu kompaniju Linux naudoja?

        • Laurynas

          Naudoja Google (GOOG), RedhHat (RHT), Novell (NOVL), NYSE, pakaks?

        • Manau, kad naudoja 90% serveriu, jeigu ne daugiau. Bet ar del to, kad kazkas naudoja, automatiskai tas daigtas tampa geriausiu KONKRECIU atveju.
          Tai, kad Lietuvoje daugiausia VW markes automobiliu, ar tai reiskia, kad jie tinka visiems ir visur?
          Norisi konkreciu sulyginimu, isreisktais pinigais :)

    • Nu jeigu tik 0.5% vartotoju, tai turbut tikrai neverta del kazko jaudintis. Svarbiausia, kad tie vartotojai nebutu mano klientai. O Lynx kiek turi vartotoju?

  4. bst

    @audrius: linux naudoja visi, kam atsibodo moketi uz AIX ar HPUX ar Solaris; arba jei softo vendorius pageidauja labiau linux nei Windows (vien del atviro kodo). Atvirai sakant sunku butu rasti serveriniu be linux.

    “linux yra opensource ir kiek, ir kokiu kompaniju Linux naudoja?” – durkit pirstu i bet kuria didesne ir rasit to linux pilna.
    Bankai naudoja. Ir dar kaip.

    • Butent tai ir norejau pasakyti, kad tai, kad programine iranga yra open, close, freeze, disband ar dar kaip nors pavadinta tai nera, nei privalumas, nei minusas. Taip, pat nera joks privalumas, kad ja naudoja bankas, ar dar kokia nors imone.
      Privalumas yra tada, kai PI issprendzia problema, o ne sukuria. O jau kiekvienam spresti, kiek jis nori moketi uz problemos sprendima. Beje programu “kreivas” veikimas yra vienas is dydziausiu mudu sutinkamu PI. Pats legviausias budas pasitikrinti, kokia yra IT mudos kaina yra toks. Pasiimi exceli ir i ji suvedi strukturuotai duomenys. Pamatuoji laika. Toliau pasiimi softa ir tuos pacius duomenys suvedi. Skirtumas tarp excel ir softo suvedimo yra muda. Kiekviena minute imone moka pinigus darbuotojams ir mes galime suskaiciuoti kiek ta muda kainavo imonei.
      Butent i tai reikia akcentuoti opensource projektus. Nes bet koks savininkas skaiciuoja TCO ir i ji itraukia ne tik tiesioginius kastus, bet ir netiesioginius. Daznai del netiesioginiu kastu opensource projektai pralosia. Ir man labai gaila, kad taip atsitinka, nes zmones juos darantys atlieka darba su meile, tik uzmirsta apie materialistini vartotoja. Kuriam, kaina nulis jau atrodo per brangu.
      Dekui, kad suteikete minciu dar vienam irasui :)

      • Laurynas

        Jo… Sorry, Audriau, del Tavo komentaru unsubscribinu sita bloga. Lyginti prie ERP lygio privestus JAVA frameworkus is Apache su Excell… Stai cia ir yra muda.
        O beje, pats linuxa tubut irgi naudoji, jei telefone Android. Arba jei GPS yra Garmin. Sekmes sviecantis.

  5. Aš siūlau pritaikyti Goldratt siūlomus metodus ir naudodami cause-effect diagramą paieškoti kur yra šakninė problema? Oj… pavėlavau, jau tai padarėm ir netgi parašėm:

    “Prieš atsakydami, prisiminkime, kad užsakovui neįdomu, kaip jūs projektą vykdote, jam įdomu tik – kada ir už kiek. Projekto vadovui įdomu, kaip vykdome projektą, ir kad visi komandos nariai turėtų darbo, o komandos nariams, neįdomu, kaip sekasi projektas, svarbiausia kaip nors atlikti savo darbus. Kaip matote, nėra bendro tikslo, ir todėl kiekvienas rūpinasi tik savim.”

    Tad pagalvokim kaip ją spręsti. Oj… tai jau irgi padarėm: “Norėtųsi surasti programinę įrangą, kuri apjungtų projektų portfelio valdymą, projektų valdymą su CCPM ir užduočių valdymą, ir kuri realiai veiktų.”

    Tik aš drįsčiau paprieštarauti, kad ne visai teisingai. Jei problema yra kad “nėra bendro tikslo” tai gal ir reikia nuo jos pradėti spęsti? Kad užsakovas, projekto vadovas ir įgyvendinanti komanda turėtų BENDRĄ tikslą ir jo siektų? Kaip galime tikėtis iš komandos siekti bendro tikslo jei ieškome įrankių, į kuriuos sukišti protingiausi mūsų darbuotojai tampa tiesiog “resursais”, kurie “protingų” projektų vadovų lengvai dėliojami kaip blokeliai… Nenuostabu kad jie tam kiek gali priešinasi. Nenuostabu kad klientas tokiu projektu nesidomi. Nenuostabu, kad ne visi projektai sėkmingai baigiasi.

    Įdomu tai, kad Agile bendruomenė šią šakninę problemą identifikavo seniai, o oficialiai pasiūlė būdus kaip tai spręsti jau prieš 10 metų: http://agilemanifesto.org. Lietuvoje tik pradedame apie tai kalbėti, ir kaip matosi dar reikės ilgai dirbti, kad įveikti standartinį mąstymą, kad klientai sėkmingų projektų nenori, o darbuotojams taip pat projektų sėmė nerūpi, tik jų užduotėlės. Džiugu kai savo kailiu patiri kiek naudos gali atnešti šitų mitų sulaužymas, ir kai gali drąsiai visiem pasakyti: “Agile metodai veikia, “netgi” ir Lietuvoje (čia kai kam vis atrodo kad mes ir mūsų projektai kitokie nei visam pasaulyje :) ). Didžiausias stabdis šiems metodams plisti yra projektų vadovai ir vadovai, kurie nenori patikėti, kad jų darbuotojai gali patys mąstyti (taip, projektų vadovams reikia rūpintis rezultatais (tikslų pasiekimu), bet ne už darbuotojus galvoti kaip atlikti kiekvieną užduotį)”.

    p.s. jei galima autoriaus paprašyti pakeisti nuorodą į straipsnį apie Kanban (vieną iš Agile metodų) į straipsnį apie Scrum. Agile, Scrum, Kanban, XP, TDD… yra ne tas pats :) Nereiktų klkaidinti skaitytojų.

    • Nieko asmeniško, bet Kanban’as atsirado dar tada kai softu užsiiminėjo tik keli šimtai žmonių visame pasaulyje. O Toyota valdė savo gamybą Kanban’o pagalba, todėl nereiktų teikti, kad Kanban’as kaip metodika yra vienas is Agile metodų… Galbūt atvirkščiai…

      • Sveikas Nerijau, tikrai nieko asmeniško. Taip, tu teisus, Kanban (“vizuali kortelė” japoniškai) atsirado seniai, Japonijoje, Tojotos (lean) produkcijos sistemoje. Agile labai smarkiai remiasi butent Lean mastymu ir Japonijos patirtimi. Taigi tikrai nėra ginčų kas atsirado anksčiau.

        Nepaisant to, po Agile skėtiniu terminu jam atsiradus buvo sutalpinta nemažai metodų, kurie atitinka Agile manifestą. Kai kurie metodų panaudojo jau naudojamus vardus, kaip nutiko ir su Kanban (ar Lean Software Developoment). Taigi ką Agile bendruomenė turi omeny vadindama vieną iš Agile metodų “Kanban” yra visai kas kita kas yra kanban metodika Tojotos sistemoje. Todėl ir siūliau jei jau kalbam apie Scrum, dėti nuorodą į Scrum :) tikrai nenori veltis į ginčus ar gerai turėti tą patį pavadinimą dviem, truputį skirtingiem dalykam, (nors Agile metodas Kanban, tikrai turi daug gerų savybių paėmęs būtent iš Japoniškojo kanban), palikim tai metodų autoriams :)

        Kam įdomu daugiau apie isotriją ir skirtumus galit paskaityti čia: http://www.crisp.se/kanban

        • Tame straipsnyje apie Kanban yra labai geras pasakymas “Kanban is just about managing workflow”, todel as nelabai matau didelio skirtumo, ar paimsime Kanban aprasyma is TPS, LEAN ar Agile, kur jis yra naudojamas. Nebent Agile nori suteikti kazkokia ypatinga reiksme Kanban?

        • Vaidijau, nieko asmeniško, bet as Nerius, be J :)

  6. Gaila, kad Laurynas įsižeidė už palyginimą su Exceliu. Nors pats sau leido alyginti IE9 su skaitliukais… O aš taip norėjau jį pakviesti į renginuką apie technologijų (ne)naudą ir technologinių start-up’ų esminę klaidą. Na bet gal kitiems bus įdomu sudalyvauti nemokamame renginyje. Daugiau info http://www.facebook.com/event.php?eid=135839563155899

    • azartas

      gal ir įdomu būtų sudalyvauti, bet matau čia tik feisbuko vartotojams, paprastiems mirtingiesiems nepavyks užsiregistruoti į seminarą paspaudus mygtuką Aš dalyvausiu :)

    • Laurynas

      @ nerius. Nei as isizeidziau, nei ka, tiesiog unsubscribinau. Nematau dideles prasmes nuolat sekti bloga, kuriame siekiama skaitytojus sviesti/mokyti dirbti racionaliai ir tuo pat browseris su 0,59% vartotoju pateikiamas vos ne kaip must have standartas.
      Plius, man parasius apie frameworkus, is karto prikisama, kad opensource yra “vat, vat…”. Tiesa, paskui audrius issivyniojo, kad nesvarbu- open ar ne open, bet visas sitas susikomentavimas apie opensourca buvo bullshitas ne i tema.
      O FB nenaudoju, galit kviest nekivete. Nebent butu galima registruotis ir be FB. Sekmes.

    • “Lemtinga technologinių start-up’ų klaida”:

      Technologijų startuoliai (start-ups) – vienas iš ateities ekonomikos variklių. Tačiau mažiau nei 10% visų technologinių verslo idėjų tampa iš tikrųjų pelningomis. Kitos numiršta ar vegetuoja taip ir nepasiekusios pelningumo taško.

      balandžio 6 dieną 16.00-19.00

      Daugiau info ir registracija pas: http://www.hubvilnius.lt/narys/mindaugas/

  7. @Audrius: as ir nenoriu pasakyti kad yra esminis skirtumas. As tik nesupratau rysio, kai pastraipoje kalbama apie viena is Agile metodu Scrum, o nuoroda yra i straipsini apie Kanban. Tik tiek man nesusisiejo :) As tikrai nemanau kad verta gincytis del pavadinimu.

    Grazios dienos!

    • As kai mokinuosi issikiriu kelis etapus:
      1. Kai viskas nerealiai idomu
      2. Kai visur neveikia
      3. Kai pradedi pastebeti skirtumus – tiek interpretacijose, tiek naudojamuose. Daznai tai vadinu patirtimi.

      Todel pas mane visada yra klausimas apie skirtumus, nes tai mano supratimu yra patirties pasidalinimas. O tai, kad pastebejote, kad yra skirtumas tarp Kanbanu – didelis dekui.

  8. bst

    Na, jei jau apie mokymasi, pazinima && klaidas:
    http://www.youtube.com/watch?v=MzS5V5-0VsA
    have a look.

  9. Thank you for all of the effort on this blog

Jūsų komentaras