Idite sa nama

pravim korakom

u vašu budućnost.

Freelanceri kao project manageri za Online, CRM i programiranje sistema1257 downloads 291.91 KB

Download

The post Freelanceri kao project manageri za Online, CRM i programiranje sistema appeared first on Dimention GmbH.

Idite sa nama

pravim korakom

u vašu budućnost.

Freelanceri kao urednici za pisanje članaka na nemačkom jeziku1233 downloads 316.80 KB

Download

The post Freelanceri kao urednici za pisanje članaka na nemačkom jeziku appeared first on Dimention GmbH.

Idite sa nama

pravim korakom

u vašu budućnost.

Freelanceri za grafički dizajn i web dizajn (WordPress)1291 downloads 342.78 KB

Download

The post Freelanceri za grafički dizajn i web dizajn (WordPress) appeared first on Dimention GmbH.

Idite sa nama

pravim korakom

u vašu budućnost.

Freelanceri frontend programeri za HTML, PHP, JavaScript i Core1311 downloads 299.49 KB

Download

The post Freelanceri frontend programeri za HTML, PHP, JavaScript i Core appeared first on Dimention GmbH.

Idite sa nama

pravim korakom

u vašu budućnost.

Freelanceri programeri za baze podataka1309 downloads 270.58 KB

Download

The post Freelanceri programeri za baze podataka appeared first on Dimention GmbH.

Idite sa nama

pravim korakom

u vašu budućnost.

Freelanceri backend programeri za programe PHP, Java, .NET ili C#1482 downloads 298.03 KB

Download

The post Freelanceri backend programeri za programe PHP, Java, .NET ili C# appeared first on Dimention GmbH.

Projektne faze digitalnog projekta

U ovom članku ponovo se osvrćemo na faze digitalnog projekta, kako bismo pokazali koliko su specifične pri uvođenju novog sistema za do sada nekorišćene procese. Ovde treba naglasiti da nije reč o zameni postojećeg rešenja novim.

Osobenosti novih sistema mogu biti predstvaljene kao prednosti i mane.

Prednosti

• Kod novih sistema uvek se polazi od nule, a to znači: niti je potrebno uzimati u obzir stare nerešene probleme, niti je prisutna migracija podataka.
• Sistem je moguće prilagoditi i podesiti zahtevima, baš onako kako je potrebno da bude.
• Operativni biznis kod novih sistema još uvek nije u tolikoj meri involviran, obzirom da nije neohodno stalno ažuriranje sistema.
• Obzirom da se procesi sporo menjaju, opšti uslovi sistema ostaju stabilni.

Mane

• Najveća mana je činjenica, da je sistem nov i da nimalo iskustva nije stečeno u radu sa njim.
• Upravo nedostatak iskustva u radu sa novim sistemima otvara brojna pitanja:
  • Koje su važne tačke koje je potrebno definisati?
  • Koje funkcije su bitne, koje nisu?
  • Kakvo je iskustvo korisnika?
  • Koje je sve sisteme potrebno involvirati?
  • Šta čini sistem komplikovanim, a šta ne?
  • Kako se povezuje sa drugim sistemima?
  • Ko je vlasnik?
  • Kako na kraju da povežem novi sistem sa procesima?
  • Kako korisnici da primenjuju sistem i kako ih pridobiti da ga zaista koriste?

1. Inicijalizacija projekta

Pretpostavimo da je reč o projektu preko 50.000 evra koji treba da prođe postupke odobrenja preduzeća.

• Sužavanje obima (scope)

U fazi inicijalizacije projekta nastaje ideja. Stoga ova faza odmah mora istaknuti šta sistem treba da postigne i koje procese da pokrije.

Ako je obim (zbir svih zahteva koje sistem treba da pokrije) uzak, tada je i sistem mali i pregledan, ali je korist eventualno suviše mala da bi stigao na dnevni red.

Ako je obim suviše širok, moguće je da su troškovi previsoki pa projekat postaje preobiman.

• Način postupanja

Naručiocu je neophodno dostaviti izveštaj o strategijskom značaju, budžetu, rešenju problema i korisnicima. Potrebno je stvoriti jasnu sliku o tome koju pažnju menadžment poklanja tom sistemu (pre svega koje ciljeve i zaradu odnosno koju dobrobit projekat treba da donese čitavom poduhvatu).

Ali ovde se ne radi o tačnoj definiciji postupka, jer ona naručiocu neće biti ni od kakve koristi. Iz njegovog ugla posmatrano, jednostavno je potrebno razraditi ga.

Važno je steći predstavu o tome i nadalje u krugu glasati o svemu. Pri tome je pre preporučljivo zalaženje u detalje, čak i ako tokom radionicam dođe do izmena, nego rad sa nejasnim idejama koje bude različita očekivanja na različitim odeljenjima i različitim nivoima. Naime, preciznost detalja je više prednost nego mana.

Odobravaju se prvi resursi za grube koncepte i postalvja se grubi koncept. Definišu se grubi zahtevi, prednosti i troškovi. Ako su obim projekta i grubo razumevanje iznad business case-a, mogu se uočiti strateške i finansijske prednosti.

Sledi procena troškova kroz razgovore sa sopstvenim IT odeljenjem, eventualno i prve procene firmi i eksternih konsultanata. Poslednji korak ove faze pre odluke menadžmenta jeste postavljanje business case-a, koji će sve da obuhvati, uključujući i projaktni tim, koji realizuje projekat, i projektni plan.

Sada predstoji odluka menadžmenta o daljem vođenju projekta. Ovo podrazumeva razvijanje obrasca za odluke za naredne korake, procenjivanje troškova za fazu detaljnog koncepta, definisanje projektnog tima i eksternih konsultanata i eventualno raspisivanje tendera.

Ako ništa ne sprečava dalje vođenje projekta, odobravaju se sredstva za detaljan koncept.

2. Detaljan koncept  (setup projekta)

• Izrada detaljnog koncepta

Najpre se pokušava grubi koncept razložiti u detalje, kako bi se procenili troškovi. Već u ovoj fazi moraju se definisati mnogi aspekti. Ali upravo to često predstavlja teškoću stručnim odeljenjima, jer imaju pune ruke posla.
Često se ova tačka ne razmatra dovoljno precizno, jer je već na ovom stepenu detaljisanja potrebno doneti odluku za rešenje. Tako, na primer, klijent može jednu ili deset slika da posatvi pomoću altke, kao zip folder ili svaku pojedinačno. Zbog straha od opredeljenja ovakve odluke se ne donose, koncept i dalje ostaje neodređen, a procena troškova nedovoljno pouzdana.
U ovom trenutku važno je skicirati rešenje, čak i ako će ono kasnije biti izmenjeno. Na taj način sve izmene troškova ostaju transparentne. Preporučljivije je da se put za rešenje menja naknadno, ali preciznije, nego da ostaje nedefinisan.

Ne sme se zaboraviti da detaljan koncept i dalje predstavlja samo specifikaciju posla, a ne tehničko rešenje. Detaljan koncept uključuje korisnike, uloge, veze, procese, neophodna polja podataka, MockUp-ove i scenarije grešaka.

• Procena pomoću IT odeljenja

Čim je detaljan koncept do pojedinosti opisan, IT kreira rešenje zasnovano na postojećim resursima i znanjima. To rešenje sadrži predloge o tome, koji deo rešenja se interno, a koji eksterno odvoja. Pošto je ova tema nova za IT odeljenje, teško je dati neku procenu. Mnogo toga ovde zavisi od ličnosti zaposlenih, od toga da li procenjuju previsokim trud koji je potrebno uložiti, da li IT vodi previše ili premalo računa o bezbednosti i da li se upušta u rizike. Pri preuzimanju u business case ovo obavezno treba uzeti u obzir.

• Odluke make-or-buy

Čim se da predlog da se jedan deo rešenja eksterno obavi, menadžment mora doneti odluku make-or-buy. Obzirom da je reč o novom rešenju, moguća su tri puta:

• Rešenje se kupuje kompletno novo.
• Rešenje se programira u sopstevnom preduzeću, jer je prisutno znanje i stručnost.
• Radi se na proširenju znanja, pa se rešenje programira u sopstevnom preduzeću.

Koji će od ova tri načina biti odabran, zavisi od strateškog značaja teme.

• Procena troškova i raspisivanje tendera (takođe uz sopstveno IT odeljenje)

Ukoliko je sve definisano, stvarni troškovi se mogu detaljno proceniti. Za eksterne usluge sledi raspisivanje tendera odnosno potrebno je pribaviti procene troškova od dvojice dobavljača.
Loše posledice moglo  bi da ima, ukoliko detaljan koncept nije dovoljno precizan. IT odeljenje to neće moći proceniti, već će kod nesigurnosti obezbeđivati doplate za bezbedno postizanje rešenja. To bi moglo biti veoma skupo, pa bi troškovi neproporcionalno rasli. Zbog toga je važno izbeći ovo.

• Odluka oko realizacije i DL (download?)

Ako su poznati svi troškovi, može se početi sa kreiranjem finalnog obrasca za odluke, kako bi menadžmentu bili prikazani tačni troškovi.

3. Realizacija

Čim je odluka pala, može se započeti sa stvarnom realizacijom.

Od ovog trenutka dolaze do izražaja prednosti stvaranja novog softvera za novu temu. Sistem se stvara od samog početka i prilagođava se postojećim zahtevima. Kako će se dalje odvijati programiranje, uvođenje (kod postojećih rešenja) ili prilagođavanje sistema zavisi od IT odljenja i DL-a, ali spada takođe pod odgovornost tehničkog vođe projekta.

Šta je važno za digitalnog vođu projekta  pri realizaciji novog sistema (interfejs između stručnih odeljenja i IT odeljenja)

• Planiranje novih projekata Planiranje treba da usledi preko više distribucija i u vidu manjih paketa. Stalno će se pojavljivati zamke, koje će prouzrokovati pomeranja i kašnjenja. Za svako distriburanje potrebno je odvojiti i dovljno vremena za testove. U to se ubrajaju kako funkcionalni testovi tako i nadgledanja realizacije zahteva.
• Zamke Pošto je realizacija projekta najvažniji deo, posebno je važno imati u vidu faktore budžet, vreme i kvalitet. Kod novih rešenja mogu se javiti zamke tj. zahtevi mogu dovesti do tehničkih problema koji će postati uočljivi tek pri programiranju. Važno je izolovati ovakve zamke i definisati moguće alternative. Pritom bi trebalo iz ugla poslovanja odlučiti, šta je važnije. Takođe može biti od značaja pridržavati se zahteva, čak i ako programiranje zahteva više rada i napora, ili zahteve prilagoditi tako da programiranje brže napreduje.
• Paralelno stvaranje više sistema
  
  Kada se paralelno programira, treba voditi računa o usklađivanju dokumenata. Naime, u toku realizacije svugde je potrebno izvoditi mala odstupanja od sistema. Njih je potrebno zabeležiti i komutirati za ostale sisteme. Često se javljaju greške, pa se tako razilaze dve linije stvaranja i ne dolazi do komutiranja.
• Uključivanje naručioca Kod novog sistema i nove usluge može uprkos temeljnoj specifikaciji da se desi da se zamisao i realizacija ne poklope. Ukoliko pre naručioci mogu da vide, testiraju ili ispitaju određene stvari, utoliko su pre u stanju da definišu izmene. Treba strogo izbegavati programiranje sistema u trajanju od dva do tri meseca, a tek potom prezentovanje rezultata. Posle toga je sa sigurnošću potrebno uraditi velike izmene. Zbog toga bi trebalo, na koji god način, sprovoditi usklađivanje između rešenja i očekivanja naručioca na svake dve nedelje.
• Funkcionalno testiranje
  
  Nakon programiranja odnosno pre spajanja (Merger) i pre integracijskog testiranja trebalo bi testirati i proveriti funkcije. Često se ovaj korak ne odvija dovoljno temeljno, pa potom integracijski testovi i testovi prihvatljivosti bivaju blokirani i kasne. Osim toga, novi softver poprima loš imidž ako osnovni dugmići ne funkcionišu ili ako na testovima isplivaju suviše očigledne greške (npr. ne funkcioniše download). Osim toga trebalo bi odlučiti da li previše grešaka u kategoriji blokera eventualno znači da se sa distribuiranjem ide na zajedničko okruženje za testiranje.

4. Testiranje

• Integracijski testovi

Ako je izveden i poslednji korak realizacije, svi pojedinačni softverski paketi mogu se svesti, povezati i testirati na zajedničko okruženje. Sada je moguće ispitati i testirati sve definisane integracijske testove i slučajeve interfejsa. Podaci i slučajevi interfejsa već su definisani u realizaciji i potrebno ih je samo još realizovati.
I ovde je bitno da su interfejs i protoci podataka testirani u svim varijantama. To se ne odnosi samo na utvrđivanje ispravnosti (ono što treba da funkcioniše), već i na utvrđivanje neispravnosti (ono što ne treba da funkcioniše).
Od ovog momenta može se dati odobrenje čitavog okruženja za testove prihvatljivosti. U tom potezu trebalo bi stvoriti naloge, pristupe i podatke, kako bi stajali na raspolaganju za testove prihvatljivosti.

• Testovi prihvatljivosti

Mogu se proveriti e2e-testovi sa podacima. Pritom u najboljem slučaju ne bi trebalo više da se utvrde odstupanja od zahteva. Ako bi se to ipak desilo, imalo bi ogromne posledice po čitavo rešenje. Na primer, ako se utvrdi da je zavisnost od dva podešavanja neispravna, potrebno je vratiti se u osnovno projektovanje rešenja i time ponoviti ukupan postupak funkcionalnih i integracijskih testova. Na testu prihvatljivosti trebalo bi u najboljem slučaju da se pojave sadržajne greške, eventualno da su vrednosti pogrešno interpretirane ili određeni podaci da nisu prikazani. Na kraju se vide sve utvrđene i prema posledicama pozicionirane greške. Na taj način menadžment može da odluči, da li bi u datim uslovima lansiranje bilo pametno.

Pogotovo kada je reč o novim rešenjima, spisak može biti poprilično dug. Ipak ne treba biti suviše restriktivan u tim slučajevima. Ako se ne radi o stvarnim blokerima u glavnim procesima, preporučljivo je pokrenuti rešenje, a ostale greške popravljati u radnom režimu. Često se neiznuđene greške ispostavljaju kao ne toliko važne, pa je pažnja na važne greške u radnom režimu znatno veća nego u fazi programiranja.
5. Prelaz u radni režim

Faza prelaza u radni režim novog sistema započinje već sa testiranjem odnosno pre njega, ako je potrebna za testiranje.
Ove se prikupljaju sve potrebne informacije o sistemu za sve stakeholdere. Počev od čistih informacija, kao na primer kao novost da se alatka pušta u rad pa sve do detaljnog materijala za obuku svih korisničkih grupa.
Pogotovo novi sistemi moraju biti detaljni i sadržati opise grešaka, kako funkcije, koje su namerno postavljene, ne bi bile prepoznate kao greške.

Osim objašnjenih funkcija dodeljuju se i vremena.

• Tehnički prelaz na radni režim: ovde se vode razgovori sa odeljenjem za tehniku o tome koje podatke, kada i u koji sistem treba ubaciti, da bi u trenutku lansiranja sve besprekorno funkcionisalo. Kod novih sistema ovo nije toliko važno.
• Stručni prelaz u radni režim: kod novih sistema potrebno je odrediti tačno vreme za sve stakeholdere, kojim se određuje koje komponente će kojim korisnicima kada biti dostupne.
• Takođe se određuje da li će postojati interna test faza za zaposlene i potom soft launch, kada počinje marketing i kada se može računati na veći porast.

6. Završetak projekta Faza stabilizacije

Završetak projekta kod novih rešenja ne bi trebalo da se poklapa sa puštanjem u rad, već bi ga trebalo planirati za oko tri meseca nakon puštanja u rad. Tako se obezbeđuje da zaposleni na projektu, koji do tog momenta već velikim znanjem raspolažu, stoje na raspolaganju onim zaposlenima za rešenje problema, koji su zaduženi za sistem od momenta puštanja u rad, ali koji su za to kratko vreme svega malo iskustva stekli u vezi sa njim. To se često previđa. Projekat se završava nakon puštanja u rad, zaposleni na projektu napuštaju projekat, a zaposleni na projektu u radnom režimu suočeni su sa pitanjima, na koja ne mogu da odgovore. Kao posledica toga vreme za pronalaženje odgovora traje predugo ili se u najgorem slučaju  problemi uopšte ne rešavaju.

Ako je sve ovo obavljeno, završen je novi digitalni projekat i lansiran novi softver sa novim procesima i novim znanjem. Na taj način postavljeni ciljevi će biti ispunjeni.

The post Uprevljanje digitalnim projektima na uvođenju novih sistema appeared first on Dimention GmbH.

1. Inicijalizacija projekta
2. Detaljan koncept (setup projekta)
3. Realizacija
4. Testiranje
5. Prelaz u radni režim
6. Projektno administrativna inicijalizacija

Projektne faze digitalnog projekta

1. 1. Inicijalizacija projekta

Prvi korak je kod većine stvari ujedno i najteži. Ovo važi i za prvu fazu digitalnog projekta. Često joj se ne poklanja dovoljno pažnje, što će reći da je najmanje opisana, analizirana i aktivno sprovođena unutar preduzeća.

Ova faza daje odgovore na sledeća pitanja: kako nastaju ideje za nove IT projekte, kako se one procenjuju i koje se sprovode dalje?

Kod ove faze razlikujemo i četiri podfaze:

•  Nastanak ideje: ovaj korak označava identifikovanje slučaja korišćenja (use cases) novih sistema. Use cases nisu nikakve funkcije ili sistemi, ali su prikazani uz pomoć sistema.
•  Ocenjivanje ideje: posle nastanka ideja izrađuje se lista sa idejama. Ideje u ovom obliku još uvek ne mogu da se koriste i primenjuju, pa zbog toga moraju biti ocenjene i svedene na određenu meru. Na taj način nastaju grubi koncepti. Već je ovde neophodan pažljiv izbor, jer stvaranje grubog koncepta obavezuje na resurse, a oni su investicija.
•  Grubi koncepti: jedan od najvažnijih zadataka ove podfaze jeste opis novih investicija. U ovoj podfazi nastaju koncept visokog nivoa i use cases. Osim toga diskutuje se sa IT odeljenjem o mogućem rešenju i procenjuju se troškovi.
•  Izbor grubih koncepata: ovde je neophodna odluka menadžmenta kako bi se odredili projekti od najvišeg strateškog značaja i sa najvećom zaradom. Vrši se filtriranje onih grubih koncepata, koji će zaista biti dalje vođeni. Ostali idu na čekanje, kako bi se realizovali kasnije ili nikad.

2. Detaljan koncept (setup projekta)

U zavisnosti od toga koliko je neki projekat hitan, ova faza može različito dugo da traje i direktno prelazi u fazu realizacije. Međutim, ona često traje veoma kratko, pri čemu bi trebalo dobro razmisliti. Jer ukoliko se tačnije definiše novo programiranje, utoliko pre će realizacija i testiranje predstavljati try-and-error postupak nego ciljano upravljanje izradom. Ovu odluku treba donositi za svaki projekat pojedinačno.

I ova faza ima podfaze: detaljan koncept u užem smislu i priprema projekta.

•  U detaljnom konceptu se definišu i evidentiraju sve potrebne tačke za ispravnu procenu troškova i planiranje projekta.
• – Ovde treba računati na veće investicije, jer koncepcioni tim obuhvata vođe projekata, stručna odeljenja, IT i eventualno eksterno znanje (analize tržišta ili eksterno IT znanje)
• – Cilj ove podfaze je stručno definisanje svih uloga, procesa i slučaja korišćenja i shodno tome pravljenje specifikacije proizvoda. Ovo je interaktivni proces.

Tek kada menadžment ima jasnu sliku o troškovima i naporima za potencijalni projekat, može da odluči da li će zaista realizovati projekat.

Detaljan koncept je ponekad najvažniji korak u procesu i zahteva najviše spretnosti. Potrebno je od stručnih odeljenja prikupiti informacije o novim programiranjima, o kojima ni sama odeljenja nemaju još tačnu predstavu. Istovremeno te informacije treba konkretizovati tako, da potom programeri tačno shvataju, šta se traži.

U mnogim slučajevima projekti se posle ove faze zaustavljaju, ako detaljni zahtevi pokažu da je projekat suviše skup i obiman.

Ovde se takođe definišu test case-ovi, koji se kasnije testiraju i u cilju pripreme prilagođavaju za prelaz u radni režim.

•  Priprema projekta – Kada se menadžment odlučio za projekat, projekat treba pripremiti za realizaciju.

Setup definiše sledeće zadatke:

• – Tim: Šta radi sam tim i pomoću kojih resursa? (interno, eksterno)
• Make or buy: Šta se kupuje i za šta se angažuju stručnjaci spolja (outsourcing)?
• – Vreme: Koje vreme stoji na raspolaganju za projekat?
• – Projektna dokumentacija: Kako treba da se odvijaju pojedinačni koraci, raspodeli budžet i šta treba da budu prvi rezultati?
• – Upravljački komitet: Kako je moguće donositi odluke u hodu i nadgledati napredak projekta?

Od ovog momenta ne samo da je jasno šta treba da se radi, već je propisano i na koji način treba raditi, kome je zadatak dodeljen, koliko vremena je predviđeno za to i koliki budžet stoji na raspolaganju. Tek sada ima smisla pristupiti realizaciji projekta.

3. Realizacija

U ovoj fazi projekat se sprovodi u delo. U zavisnosti od veličine projekta i filozofije preduzeća definiše se način izrade.

Pored toga definišu se termini isporuke određenih komponenti i dostupnosti finalnog proizvoda. Važan izazov novih IT projekata je uticaj na veliki broj postojećih sistema, pri čemu je potrebno prilagoditi svaki od njih, a posebno interfejs.

IT resursi počinju sa programiranjem. Usled nedoumica IT-a ili problema oko rešenja, na sva dodatna pitanja se odgovara u određenim ciklusima. Ova faza predstavlja odlučujući korak u programiranju. Već ovde se može mnogo uštedeti na izradi, jer su prepoznatljiva rana odstupanja od željenog rezultata.

Zaposleni na digitalnim projektima bi za ovo trebalo da izdvoje dovoljno vremena i da se pobrinu za to da se koriste ciklusi za sva dodatna pitanja. Osim toga treba uzeti u obzir ne samo kulturne razlike između stručnih odeljenja i IT-a, već i između nemačkih naručilaca posla i indijskog proizvođenja. 
Ako je programiranje dalje napredovalo, otpočinju funkcionalni testovi. Oni predstavljaju kontrolu proizvoda i pokazuju da li pojedinačna rešanja imaju smisla, da li funkcionišu dugmići itd. Funkcionalni test spada još uvek u fazu programiranja, pošto je moguće i eksterno programiranje softvera. Pre sprovođenja integracije u sredinu potrebno je prilagoditi važne funkcije.

4. Testiranje

Ako je pređen i poslednji korak u okviru proizvodnje, moguće je sve softverske pakete postaviti u jednu zajedničku sredinu i potom ih povezati.

Zatim otpočinju integracijski testovi. Na taj način se proverava da li funkcionišu svi prenosi podataka i da li su sistemi performantni, a putem regresionog testa proverava se da li je poremećen rad nekih već postojećih funkcija.

Kada su ovi testovi završeni, može se početi sa pripremanjem sredine testiranja za end-2-end testove (e2e). Za to je potrebno urediti naloge, staviti na raspolaganje podatke testiranja, podesiti vreme kao i use cases (test cases) zajedno sa sistemima za praćenje. Posle toga stručna odeljenja mogu da sprovode e2e-testove i testove prihvatljivosti. Paralelno sa tim, IT može da sprovodi regresioni test, kako bi proverili da li postojeće funkcije i dalje funkcionišu.

Ako su ispitane sve važne funkcije, a prihvatljivost potvrđena, sledi prelaz na radni režim.

5. Prelaz na radni režim

Iako se ova projektna faza često zanemaruje, ona je od elemantarne važnosti za stvarnu primenu sistema i ne sme biti zaboravljena. Uprkos tome u mnogim slučajevima prelaz u radni režim se jednostavno ignoriše.

U fazi prelaza na radni režim definiše se način uvođenja sistema sa tehničke strane (tehnički prelaz na radni režim) i stručne strane (stručni prelaz u radni režim).
Budući korisnici dobijaju materijal za obuku i bivaju obučeni. Određuju se vreme ubacivanja podataka i prelaznih faza. Pogotovo kod parcijalnih rešenja tačno se definiše, koje su pomoćne metode (workaround-ovi) potrebne, kako bi se softver u potpunosti koristio.

Značaj ove faze jeste u tome, da se pri uvođenju spreči da korisnicima predati procesi odjednom više ne funkcionišu, suviše sporo rade ili da se rano otkrije kada se sistem ponaša drugačije nego što je predstavljen korisnicima.

6. Administracija (planiranje, menadžment und optimizacija)

Prelazom na radni režim projekat je završen, a inovacija plasirana na tržištu.
Ceo ovaj postupak kroz projekat prati administrativna starnica. Tu se projekat planira, definišu se i postaju opipljivi budžet, vreme, resursi i ključni indikatori efikasnosti (KPI). Njih je potrebno kontinuirano pratiti i izveštavati o njima. Po završetku projekta trebalo bi sve podatke o projektu vrednovati preko admin stranice i staviti ih na raspolaganje za nove procese učenja.
Ovo vrednovanje projekta zahteva velika ulaganja i iznosi između 15 i 20 procenata celukpne vrednosti projekta.

U naredna četiri članka objasnićemo, koje se razlike prikazuju u sadržaju kada je potrebno rešiti jedan od sledećih problema:

• Uvođenje novog sistema
• Zamena postojećeg sistema novim
• Nove funkcije za postojeći sistem
• Mali projekti do 40.000 odnosno 50.000 evra

The post Projektne faze digitalnog projekta appeared first on Dimention GmbH.

Svejedno o kojim projektima je reč – skoro da nema projekata bez IT pozadine. Kod nekih projekata je IT udeo toliko veliki, da prevaže, te je zbog toga ceo projekat nazvan digitalnim. Zbog svoje digitalne strukture i orijentacije digitalni projekti zahtevaju specijalan način upravljanja projektima koji omogućava postizanje projektnih ciljeva. Ovaj članak detaljno opisuje osobenosti postupaka ovih projekata i razloge zbog kojih zahtevaju stručna znanja.

Šta je to digitalno upravljanje projektima i šta su digitalni projekti?

Upravljanje projektima podrazumeva realizaciju projekata pod opštim uslovima vremena, budžeta i zahteva. Pritom reč projekat pokriva veliko polje značenja. Tako se pod projektom može podrazumevati sledeće:

• konstruisanje novog automobila
• projekti restruktuiranja
• strateški projekti
• i naravno digitalni projekti

Digitalni projekti su svi oni projekti koji imaju za cilj:

• uvođenje novog softvera
• proširenje softvera
• zamenu starog softvera novim.

U zavisnosti od oblasti primene softvera, on se različito programira. Stoga se na primer drugačije programira softver za mobilni telefon ili automobil od onog softvera, koji služi za automatizaciju nekih procesa. Takođe i njihovi ciljevi se međusobno razlikuju. Mogući su sledeći ciljevi:

• ušteda na troškovima kroz automatizaciju i zamenu radne snage
• minimizacija grešaka
• razvoj novog biznisa
• unapređivanje ili podrška postojećim procesima

Za sve ove namere potrebni su digitalni projekti koji postavljaju zasebne zahteve pred manadžera projekta i projktni tim.

Ko je vođa digitalnih projekata?

U principu postoje dve vrste menadžera digitalnih projekata: digitalni menadžer projekta fokusiran na poslovanje i tehnički menadžer projekta.

Menadžer projekta fokusiran na poslovanje nadgleda projekte u celosti, u koje su pored IT odeljenja uključena i druga, kao na primer marketing. Tehnički menadžer projekta odgovoran je za realizaciju u saradnju sa IT odeljenjem i pružaocima usluga.

Koji od njih ima vodeću ulogu u nekom projektu, zavisi od strukture firme i uticaja pojedinačnih odeljenja. Sadržajno bi ukupna odgovornost trebalo biti prebačena na onog menadžera projekta, koji ima veću dodatu vrednost unutar projekta.

Po čemu se razlikuju digitalni projekti od ostalih projekata?

Verovatno po mnogo čemu više nego što ste mislili. Pomenuta struktura vođenja projekta bila bi već jedna razlika. Slede ostale:

Digitalni Projekt Managment

Ovo su sve karakteristike koje ilustruju o kojim osobenostima kod digitalnih projekata treba voditi računa i šta ih razlikuje od strateških projekata.

Dobar menadžer digitalnih projekata će već tokom planiranja odnosno inicijalizacije projekta sve ovo uzeti u obzir .

Zaključak

Skoro svi projekti se u današnje vreme zasnivaju na IT-u. Oni, kod kojih IT udeo prevaže, nazivaju se digitalni projekti. Međutim, reč projekat može da ima mnogo značenja. U najširem smislu uvek se odnosi na neki planirani poduhvat.

Realizacija projekata uz poštovanje vremena, budžeta i svih zahteva naziva se upravljanje projektima. Digitalni projekti imaju za cilj uvođenje novog softvera, proširenje softvera ili zamenu starog softvera novim. U zavisnosti od područja primene i cilja softvera, on se programira na različite načine.

Postoje dve vrste menadžera digitalnih projekata: digitalni menadžer projekta fokusiran na poslovanje i tehnički menadžer projekta. Zbog toga postoje i najmanje dva odeljenja digitalnih projekata – biznis i IT.
Osim toga najvažnije osobine digitalnih projekata su:

• Autput je softver odnosno kod.
• Proces se odvija prema sledećoj šemi: prikupljanje zahteva, programiranje, testiranje i unapređivanje, predaja naručiocu i obuka.
• Proces je cikličan i podležan brzim promenama, jer jednom programiran softver stalno se dalje programira i unapređuje ili zamenjuje.
• Testiranje je ključni korak u procesu.
• Postoji zavisnost između programiranja i procesa odeljenja IT-a i pružalaca usluga.
• Postoji zavisnost između instalacije softvera i distribucje.
• Kvalitet i kod se ne mogu sagledati.
• Dolazi i do uticaja na ostale sisteme i softver.

Naredni članak posvećujemo pojedinčnim fazama digitalnog projekta.

The post Upravljanje digitalnim projektima appeared first on Dimention GmbH.

Napraviti sadržaj je maksima mnogih znamenitih medijskih kuća, kao i novih startup-firmi. Uspeh im tu daje za pravo, ako uspeh merimo brojem pritisaka na baner i brojem posetilaca odnosno odanih čitalaca. Sa ovim potencijalom moramo na kraju biti u mogućnosti da ostvarimo profit. Kako biste kao ponuđač stekli uvid u postojeće mogućnosti komercijalizcije sadržaja napravili smo pregled najčešće korišćenih načina ostvarivanja profita na sadržajima.

Pronađite u prezentaciji najvažnije informacije o različitim načinima komercijalizacije kao što su AdSense, reklamiranje, subskribovanje i mnogi drugi: 

• klasični Ads
• Ads za transakcije
• Paid Content ili direktna transakcija
• kooperacija

Reklamiranja Contenta - Pregled Mogucnosti1546 downloads 2.39 MB

Download

The post Načini komercijalizacije sadržaja (Content) appeared first on Dimention GmbH.