Štai trumpas: pirma, perkeliant kompiuterinę infrastruktūrą į nutolusią vietą, visiškai pasikeitė projekto komandos, jūsų klientų ir klientų prieiga prie infrastruktūros ir programų.
Antra, žymiai sumažėjo vietos projektų komandų skaičius ir pasikeitė tų, kurie turi likti vietoje.
Trečia, dėl to, kad programos, kuriose yra debesis, palaiko tiekėjas, pasikeitė programų kūrimo, tvarkymo ir nustatymo procesai, o projektai apima ir tas užduotis.
Aišku kaip purvas? Aš taip ir maniau! Aš paskambino Cloudwards.net vadovui "Cloud Expert" ir "Mauricio Prinzlau" generaliniam direktoriui Cloud Explain ir paaiškinti daugiau apie tai, ką projekto vadybininkai turi žinoti apie debesį ir kaip jis keičia jūsų darbo vietą. Leiskime jam perduoti ...
"Pre-Cloud" taikymo aplinka
Iki debesies atvykimo aplinka, su kuria susidūrė vidutinis projekto vadovas, atrodė panašiai: serveriai yra įmonėje, patalpose ar išorės patalpose. Klientų pusės staliniai kompiuteriai ir nešiojamieji kompiuteriai platinami bendrovės biuruose, juos valdo didelis vidinis IT personalas.
Dauguma IT sistemų kūrimo ir palaikymo vykdo kūrėjai, kuriuos sudaro didelis vidinis kūrėjų baseinas. Dalyvauja keli rangovai, tačiau dauguma darbuotojų dirba visą darbo dieną. Garsas pažįstamas Jei dirbote projektų vadovu daugiau nei penkerius ar šešerius metus, tai bus.
Pagrindinės projekto vadovo atsakomybės priešlaikybinės eros metu
Prieš debesų skaičiavimą pagrindinė atsakomybė už vidutinį projekto vadybininko programinės įrangos projektą atrodė: dirbti su techniniu architektu ir dizaineriais dėl dizaino ir architektūros poreikių. Apskaičiuokite, planuokite, prižiūrėkite, tvarkykite, stebėkite ir koordinuokite atitinkamų komandų analizę, projektavimą, kodavimą ir testavimą. Koordinuoja su verslo naudotojais priimant naudotojus ir išorines komandas, jei reikia, atliekant sistemos testavimą. Turėkite bendrą atsakomybę už pristatymą, bendraujant su vidaus komandomis, kai to reikia
Tai atrodo kaip šiandien
Dabar pažvelkime į tai, kaip projektų vadovo vaidmuo atrodo, kai įmonė naudoja išorinį tiekėją, kuri kuria ir priima paraišką savo debesies svetainėje.
Projektavimo ir architektūros darbe dalyvauja vidiniai komandos nariai. Jūs nuotoliniu būdu bendraujate tik su dizaineriais ir architektūromis iš pardavėjo pusės, jei norite, kad susitikimai vyktų vietoje
Koordinavimo pridėtinės išlaidos didėja, nes vis tiek turite prižiūrėti priežiūros pareigas nuo įvertinimo iki testavimo, bet ir su išorės tiekėjų darbuotojais. Reikia daug daugiau susitikimų.
Koordinavimas su verslo vartotojams vis dar vyksta vidiniame naudotojo priėmimo bandymui, tačiau sistemų integravimo testavimą dažniausiai atlieka išorės komandos.
Jis atrodo dar labiau skirtingas, kai įmonė naudoja tik išorinės tiekėjo priegloboje esančios programos programą.
Iš viso nereikalaujama, kad IT darbuotojai būtų kliento pusėje, ir lengviau spręsti problemas, nes bendravimas ir nuosavybė yra vienoje vietoje.
Taip pat yra galimybių gauti gerą paramą iš masto. Pavyzdžiui, jei mes manome, kad "Salesforce CRM" yra tas pats programinės įrangos egzempliorius, ta pačia architektūra internete milijonus klientų aptarnauja. "Salesforce" greitai ištaisys bet kokius iššūkius ar veiklos defektus, nes tai yra jų verslo modelio dalis.
Problemų derinimo procesas taip pat supaprastinamas, nes tai nutinka nuotolinėje svetainėje.
Tai supaprastina projekto vadovo vaidmenį.
Kaip Debesys keičia jūsų darbo vietą
Yra keletas būdų, kaip debesis keičia jūsų darbo vietą.
Pats įtakingiausias debesies pasikeitimas yra tai, kad dauguma jūsų egzistuojančių vietoje esančių infrastruktūrų praranda reikšmę. Pasibaigus debesies laikui visos jūsų programos buvo laikomos onsite serveriuose ir duomenų centruose. Kai jūsų projekto komandos perjungiamos į debesį, pardavėjas pradės teikti programinę įrangą iš nuotolinės svetainės. Tai reiškia, kad jūsų biurų ir duomenų centro erdvės reikalavimai projektams labai sumažina.
Darbuotojų požiūriu debesų atvykimas keičia darbuotojų asortimentą ir darbuotojų IT darbuotojų komandų, reikalingų norint paremti bet kokią programą, kurią pateikia jūsų projektas, dydį. Prieš debesų skaičiavimą buvo rimta alternatyva, kad jums reikėjo daugybės programų kūrėjų, techninių vadovų ir QA testerių, kad galėtumėte atlikti patobulinimus, klaidų taisymus ir plėtrą, reikalingą kaip jūsų projekto dalis. Kai perkeliate į "debesies" programas, jūsų reikalavimas dėl šių rūšių komandos sumažėja.
Trečia, priešlaikinio debesies laikotarpiu jums reikėjo didelės apimties IT darbuotojų, kad jūsų programos veiktų. Kaip projekto vadybininkas, jūs įtraukėte šiuos paramos žmones į vieną iš svarbiausių vaidmenų projekto komandoje, nes planuoti savo perdavimą yra svarbu.
Kai debesis atvyksta į jūsų įmonę, galite sumažinti savo paramos komandas ir išlaikyti esamus darbuotojus ir susieti juos su kitomis pozicijomis. Vis tiek turėsite įtraukti projekto perdavimą į savo " Ganto" diagramą , tačiau tai padarysite kitaip, ir greičiausiai tai nepadės tiek laiko.
Kita vertus, jūsų projekto komandai (ir apskritai verslui apskritai) reikės daugiau techninių architektų ir verslo analitikų nei anksčiau. Šie ekspertai galės derinti su pardavėjo darbuotojais veiksmingai taikyti taikymo sritį.
Kokie įgūdžiai yra susiję su debesų skaičiavimu iš projekto vadovų?
Tam, kad galėtumėte tvarkyti debesis pagrįstus įsipareigojimus, gali reikėti įsigyti keletą naujų projektų valdymo įgūdžių . Štai keletas svarbiausių dalykų:
1. Išplėstiniai finansiniai ir sąnaudų nustatymo įgūdžiai. Projektų vadovai turės spręsti aplinką, kuri bus paraiškų, priglobtų onsite serveriuose ir priegloboje esančiose svetainėse, derinys.
Kai bus sukurta nauja paraiška, projekto vadovai bus raginami atlikti abiejų variantų sąnaudų ir IG analizę. Tam reikia žinoti, kaip kurti projekto biudžetą, atsižvelgiant į debesis pagrįstą aplinką ir patirtį.
2. Gilesnės įmonės architektūros žinios: tai dar kartą dėl to, kad architektūrinis taikmenų vaizdas tampa sudėtingesnis po perėjimo prie debesies. Būtų reikalingos gilesnės įmonės architektūros žinios, siekiant užtikrinti, kad naujesnės programos būtų sukurtos kartu su tinkamais verslo ir techniniais reikalavimais taip, kad jos būtų vientisos su esamais debesyje ir vietoje esančiomis programomis.
3. Tiekėjo ir sutarties derybos: nors projektų vadovai visada turėjo turėti derybinių įgūdžių, perėjimas prie debesies reikalauja, kad valdytojai dažniau naudotųsi pardavėjo ir sutarčių derybų įgūdžiais.
Tai yra papildomų papildomų išlaidų aspektas, nes net mažos programos kūrimas prireiks dirbti su pardavėju, kad būtų geležies.
Vykdant debesų pagrįstą projektą, yra puiki mokymosi galimybė ir puikus būdas išplėsti savo įgūdžius!