U ovoj lekciji ćemo obrađivati:
Veliki uticaj na softversko inženjerstvo ima i menadžment ljudskih resursa. Pravila i procedure za zapošljavanje, trening i motivacija osoblja kao i praćenje razvoja karijere zaposlenih važni su, ne samo na nivou datog projekta, već predstavljaju dugoročno ključan faktor razvoja organizacije.
HR menadžment u oblasti softverskog inženjerstva predstavlja poseban izazov s obzirom na brzinu promena tehnologije i potrebnu obučenost zaposlenih. Insistiranje na konstantnim obukama i sticanje novih znanja i veština neki su od ključnih elemenata uspešnog rada sa razvojnim timom. Ostati u toku sa promenama, uvek vladati najnovijim alatima i razvojnim tehnologijama, velika je i konkurentska prednost na tržištu.
Komunikacioni menadžment je posebno važan zbog potreba preciznog razumevanja među članovima tima i usled kompleksnosti zahteva i njihovog jasnog razumevanja. Postoji konstantna potreba za jasnom sveukupnom vizijom, ne samo softvera koji se razvija, već i softvera koji već postoji u organizaciji. Ponovno korišćenje softvera u tom slučaju igra veliku ulogu u održavanju i unapređivanju produktivnosti.
Dva programera sa istim sposobnostima i interesovanjima uvek mogu da se razlikuju po iskustvu ili stepenu poznavanja sličnih aplikacija, alata ili tehnika. Neko ko je već uspešno koristio jezik C za pisanje komunikacionih komponenti, verovatno će na C-u brže napisati nove komunikacione komponente, nego neko ko nema nikakvo iskustvo sa jezikom C. Izbor radnika koji će biti angažovani na projektu ne obuhvata samo individualne sposobnosti i veštine, već i prethodno iskustvo i obučenost.
U svakom razvojnom projektu ili održavanju softvera, članovi razvojnog tima komuniciraju međusobno, sa korisnicima kao i sa naručiocem. Na napredovanje projekta ne utiče samo stepen komunikacije, već i sposobnost pojedinaca da saopšte svoje ideje. Softverski otkazi mogu da budu rezultat prekida u komunikaciji i međusobnog nerazumevanja. Iz ovoga sledi da broj ljudi koji komuniciraju može da utiče na kvalitet rezultujućeg proizvoda. Uvećanje radnog tima sa dve na tri osobe, utrostručuje broj mogućih komunikacionih kanala. U opštem slučaju, ako projekat ima n zaposlenih, onda postoji n(n - 1)/2 parova koji možda žele da komuniciraju. Prema tome, projekat koji npr. angažuje samo desetoro ljudi ima 45 komunikacionih kanala.
Ciklus razvoja softvera se sastoji iz više koraka, pri čemu se neki od njih ponavljaju sve dok se sistem ne završi, a naručilac i korisnik ne budu zadovoljni. Pre nego što se potvrde sredstva za realizaciju razvoja ili održavanja softvera, korisnik obično želi da proceni koliko će projekat da košta i traje. U tom smislu bitno je ispitati aktivnosti koje su neophodne za planiranje razvojnog projekta softvera i upravljanje njime. Upravljanje projektima odnosi se na definisanje i planiranje projekta kao i na postupke kontrole i zaključivanja.
Svakim projektom treba upravljati. Što je projekt veći i kompleksniji, to postoji sve veća potreba za formalnim, standardizovanim i struktuiranim procesom. Prvobitni načini razvoja bili su neformalno vođeni od strane pojedinaca.
Uvođenje formalnog pristupa i stepen njegove primene zavisi i od veličine projekta. Možda je moguće držati u mislima čitav projekt i upravljati njime ako taj projekt traje do 200 sati i u njega su uključene dve ili tri osobe. Projektom koji traje 1000 sati i uključuje 5 osoba više nije moguće upravljati na isti način. Projekt u koji je uključeno 10 osoba i za njegovo izvršenje je potrebno 5000 sati, zahteva formalniji pristup upravljanju, a projekt sa 20 ljudi i 20 000 sati još formalniji, itd...
Računarski sistemi su odavno postali veoma složeni, a softver koji se razvija ima stalnu tendenciju rasta kompleksnosti. Tržište zahteva od kompanija koje razvijaju softver sve kraće vreme razvoja softvera koje zbog toga vode bespoštednu borbu u izvršavanju poznate mantre: brže, bolje, jeftinije.
Greške koje se kasnije javljaju tokom projekta najčešće prouzrokuje manje kvalitetan postupak planiranja. Većina projekata ima dogovorene krajnje rokove, a rokovi danas postaju sve kraći i kraći. Ugovaranje rokova koji su agresivno kratki prisiljava menadžere projekta da započnu projekat što ranije moguće.
Pre nego što započne projektni posao, potrebno je provesti okvirni postupak planiranja da bi se osiguralo zajedničko razumevanje i slaganje oko projektnih poslova. To nikako nije izgubljeno vreme ili suvišni posao, već je vreme u kom menadžeri projekta osiguravaju da projektni tim i klijent stvore zajedničku percepciju rezultata projekta, da se dogovore oko okvirnog roka kad će projekat biti završen, za cenu projekta, ko će obavljati posao i na koji način.
Zatim, od velike važnosti je neophodnost postizanja slaganja i zajedničkog shvatanja projektnih ciljeva, rezultata, opsega, rizika, troškova, pristupa i dr. Određivanje valjanosti originalnog poslovnog slučaja takođe treba da se sprovede. Npr. projekat koji zahteva 10000 radnih sati može imati poslovnog smisla. Ako detaljniji postupak planiranja rezultira s tačnijom procenom od 20000 radnih sati, projekat više možda neće imati poslovnog smisla.
Jedna od ključnih koristi je i osiguravanje dostupnosti resursa kad oni budu potrebni. Važno je i definisanje osnovnih odrednica visokog nivoa opštosti uz pomoć kojih se može ocenjivati uspeh projekta.
Logično je da manji projekti zahtevaju kraći ciklus planiranja od većih projekata. Trud koji je potreban da bi se izvršilo planiranje zavisi od količine informacija i nivoa detaljnosti koju treba obraditi i dokumentovati. Trajanje definisanja posla zavisi od trajanja pronalaženja i dokumentovanja informacija kao i od trajanja pridobijanja saglasnosti i odobrenja od strane klijenta. Pre nego što ciklus razvojnog veka projekta započne (analiza, projektovanje, konstrukcija, itd), treba postaviti brojna pitanja dobijena postupkom planiranja. Za manje projekte mnogi od tih uslova su zadovoljeni implicitno ili neformalno, ali što je projekat veći, to postaje važnije formalno i eksplicitno zadovoljavanje postavljenih kriterijuma.
Opseg je način kojim se opisuju granice projekta. Opseg definše šta će se realizacijom projekta isporučiti, a šta ne. Razlozi neuspeha projekta su ili to što tim nije utrošio dovoljno vremena za definisanje posla i/ili nije postojao definisan posao upravljanja opsegom. Čak i ako je menadžer projekta učinio dobar posao pri definisanju opsega, teži deo dolazi u fazi upravljanja samim projektom u dogovorenim granicama (opseg projekta). Bez pravilne definicije opsega kroz definisanje radnih koraka, nemoguće je efikasno upravljati opsegom projekta. Dozvola izmene opsega projekta uključuje izlazak izvan opsega koji je početno dogovoren u “definiciji projekta“. Ako je opseg nejasan ili ostavlja prostor za interpretaciju, klijent može uvesti izmenu u opsegu, a menadžeru projekta će biti teško upravljati opsegom projekta.
Svrha upravljanja promenama opsega je zaštita tekuće, odobrene definicije projekta i tekućih, odobrenih poslovnih zahteva. Kada je projekat definisan, određene pretpostavke su načinjene o projektnim rezultatima koji će biti realizovani. Ako se isporuke menjaju tokom projekta (obično to znači da klijent želi dodatne stavke), kalkulacija troškova, angažman resursa i trajanje više neće važiti. Menadžer projekta može da upozori klijenta da će trošak, angažman sati i/ili trajanje biti modifikovani, najčešće povećani, kako bi odgovorili zahtevima klijenta za ovaj dodatni posao. Često su svi dodatni zahtevi i predmeti novih ugovora o isporučenim funkcionalnostima kako bi se u svakom trenutku imao jasan plan definisanih obaveza sa obe strane.