În domeniul informaticii, harta îndeletnicirilor despre care vorbeam în articolul anterior se găsește în fapt gata făcută prin cele țări străine. Ca de un exemplu la englezi, care au botezat-o SFIA1 și au construit-o în esență pe trei coordonate: categorii (tipuri) de muncă în informatică; niveluri de răspundere; abilități și cunoștințe. Practic informația e toată prezentată sub forma unei matrici bidimensionale, avand pe o latură categoriile de muncă, iar pe cealaltă nivelurile de răspundere. În fiecare căsuță (deci la intersecția unui nivel de muncă cu o anumită categorie) se află o descriere a abilităților și cunoștințelor necesare. O organizare excelentă zic eu, pentru o hartă.
Nivelurile de răspundere găsesc că sunt poate elementul cel mai puțin înțeles la noi și pe de altă parte cel cu aplicabilitate chiar și în afara informaticii, pentru că aceste niveluri de răspundere sunt valabile aș spune pentru orice domeniu și orice competențe în fapt. SFIA definește șapte astfel de niveluri: follow; assist; apply; enable; ensure, advise; initiate, influence; set strategy, inspire, mobilise. Traduse, ar putea fi: a executa (adică faci fix ce ți se spune și nimic mai mult ori în alt mod); a asista (a lucra deci supervizat în fapt, cu minim de autonomie pentru lucruri suficient de simple); a aplica (ai cunoștințele și abilitățile necesare și le poți valorifica în practică pentru contextul în care le-ai obținut); a activa (practic un pas mai departe decât aplicarea, poți folosi cunoștințele și abilitățile cu pricina în moduri ori contexte potențial noi); a asigura, a verifica, a oferi consultanță; a iniția, a influența; a stabili o strategie de lucru, a inspira, a mobiliza.
Ca o paranteză pentru informaticieni și un eventual respiro pentru restul lumii, dacă vă pare că ar fi înțelese nivelurile acestea la noi, aș fi curioasă cum se face că toată lumea, inclusiv pe bloguri, pare să fie din start pusă pe inspirat, mobilizat și stabilit strategii de lucru. Pentru alții, evident. Și tot cam evident, cum se face că nu le iese deloc-deloc. Mă gândesc că pentru răspuns la chestiune, o fi utilă o autoevaluare și recunoaștere clară a nivelului de responsabilitate la care se află fiecare la momentul curent.
Revenind la SFIA, categoriile de muncă dau în fapt o idee de ansamblu asupra subdomeniilor mari care pot fi definite pentru informaticieni. O încercare de traducere ar putea fi următoarea: strategii și arhitecturi (strategy and architecture); modificarea afacerilor (business change); proiectare și implementare (de soluții informatice) (solution development and implementation); managementul serviciilor (service management); asistență pentru aprovizionare și management (procurement and management support); interacțiune cu clienții (client interface). Fiecare categorie are apoi subcategorii, ca de exemplu asistență pentru clienți, respectiv vânzări și marketing, cele două subcategorii pentru interacțiune cu clienții.
Ideea SFIA este că poți în fapt urmări (ori construi) o carieră pe baza informației prezentate în forma asta. Din start poți vedea la un nivel general cât de variate sunt opțiunile în fiecare categorie și cât de mult ți se cere pentru a începe de acolo (în esență cu cât e nivelul de răspundere mai ridicat, cu atât cerințele sunt mai mari, evident). Unele categorii și subcategorii sunt practic extrem de accesibile (nici o surpriză că asistența pentru clienți pornește de la nivelul cel mai scăzut de răspundere), dar altele pur și simplu nu au poziții la niveluri atât de scăzute de competență: trebuie să îți formezi întâi un nivel de competență, fie prin studiu fie prin activitate în alte categorii. Evaluând onest unde te afli în fapt și stabilindu-ți clar unde vrei să ajungi, SFIA îți poate indica ce îți rămâne de făcut. Evident, nu-ți face și treaba în sine, asta e.
Las drept exercițiu pentru cine dorește să numere cam câte din subcategorii sunt măcar reprezentate cu adevărat în România. Cam în ce subcategorii se angajează preponderent studenții și absolvenții din domeniu de la facultățile din România. Și pentru ce anume sunt în fapt pregătiți studenții cu pricina, mai ales atâta vreme cât nici măcar nu le e pusă în față o hartă de tipul acesta.
Skills Framework for the Information Age. ↩
Comments feed: RSS 2.0
"toată lumea, inclusiv pe bloguri, pare să fie din start pusă pe inspirat, mobilizat și stabilit strategii de lucru. Pentru alții, evident." - as in telling others what language is best to write in? :)
@asa.zamo.ca Fix ca in aia (desi in fapt e ceva mai mult decat ce zici tu acolo). Dar cine zice cui in ce limba e cel mai bine sa scrie? Zic sa nu confundam o discutie pe subiect cu indicatii pretioase...
Activitatile cu "level mic" sunt din ce in ce mai mult externalizate "din vest" catre pietele cu forta de munca specializata si costuri mici. Vazut "de departe" imi pare (dar poate ma insel ?) ca Romania si-a capatat un statut de care nu mai scapa ala de "low cost" taman bun pentru ousourcing cu costuri reduse. De unde si limitarea informatician = programator la care faceai referire. Cum s-ar spune, s-a adaptat cererii.
@dana Observi tu acolo o realitate intr-adevar, parte din ce voiam sa expun: faptul ca in Romania in fapt IT la momentul asta se face doar la nivel de baza. Chestiunea insa imi pare ca e faptul ca nici n-are cum sa se faca la alt nivel pana cand nu recunoastem intai ca asta este tot ce avem acum si apoi ne apucam sa pregatim si oameni pentru mai mult de atat. Pentru ca atata vreme cat in fapt forta de munca existenta e toata la nivelul ala de baza (ori sub), de unde sa iasa altceva peste?
Pai explicatia "simplista" ar fi ca se fabrica ceea ce se cere . Daca ar trebui "ridicata stafeta" ar trebui creata piata de desfacere. Dar cum spui primul pas a face este constientizarea situatiei (chiar nu pot a cred ca nu se stie inca in Romania de existenta unor "meserii" de tip "Enterprise Archiect" sau "Business Architect" sau "Business Analyst" sau ...)
@dana: într-adevăr în România nu se fac chestii prea avansate sau populare, dar nu suntem singurii. Pe partea de software în afară de SUA, Israel (cu Amdocs) și Germania (cu SAP), alte țări nu prea s-au afirmat. Poate Norvegia cu Qt și Suedia cu MySQL AB care era însă prezentă și în SUA. Pe partea de hardware am avea SUA, Japonia și Israel (Alvarion și filiale Motorola, Intel). Eventual și Singapore cu firma Creative plus fabrica pentru Seagate. Tailanda, China, Taiwan (plus Mexic și Irlanda) doar fabrică, deci nu cred că pot fi încadrate la lucruri avansate.
Arhitecții ăia sunt cu dus și întors. Sunt buni pentru mamuți sau chestii financiar-contabile și cam atât. În rest, eu nu prea le văd rostul sau nu în modul pompos în care sunt promovați adeseori.
Care defapt nu sunt meserii, precum tot sectorul marketing si administratie, ci niste rahaturi de incalzit scaunuri prea bine platite, cand ar trebui sa existe o singura persoana calificata in mai multe domenii pentru un ghiseu/birou si asta e.
Intel si Costa Rica, ps.
@Cristian :
"Arhitecții ăia sunt cu dus și întors. Sunt buni pentru mamuți sau chestii financiar-contabile și cam atât. În rest, eu nu prea le văd rostul sau nu în modul pompos în care sunt promovați adeseori."
As zice ca n-au absolut nimic de-a face cu "chestiile financiar contabile". Chestia cu mamutii este partial adevarata dar numai partial. Asta daca consideri ca numai mamutii isi vad mai departe de varful nasului si abordeaza si ceva ceva din strategiile pe termen lung. Dar eu n-as generaliza . In Romania probabil ca n-au prea mare rost pentru ca abordarea este in general "pe termen scurt" dupa metoda "om vedea noi". Dar asta nu inseamna ca nu exista si ca nu sunt aplicate cu succes in alte parti. Revenim la ceea ce spuneam la inceput : cerere si oferta. Se cere soft de calitate la preturi competitive , se face soft de caliatte la preturi competitive.
@dana: eu consider că Dennis Ritchie și Ken Thompson (creatorii sistemului de operare Unix și al limbajului C) nu nici pe departe arhitecți la care faci tu referire. Iar Unix și C pot fi considere produse pe termen lung având în vedere că au fost create prin anii '70 și mulțumită evoluției sunt prezente și astăzi. Exemplele pot continua cu Linus Torvalds (Linux), Theo de Raadt (OpenBSD), jwz (Netscape - suita de dinainte de Firefox și Thunderbird, XEmacs), DHH (Ruby on Rails, 37signals), Knuth (TeX), Richard Stallman aka RMS (Emacs, GCC) și Guido van Rossum (Python). Pe niciunul din ăștia nu i-am auzit făcând pe arhitecții. Cred că nici măcar Steve Jobs din scaunul lui de mare șef nu se considera așa ceva și evita pe cât posibil asociarea cu enterprise.
Problema cu arhitecții ăștia e că văd problema nu din avion, ci din spațiul cosmic și de cele mai multe ori vin cu niște idei de te doare capul. De asta Amdocs și alte produse similare o sug. De asta configurarea semi-automată a Outlook-ului îmi oferă tot felul de posibilități de a servi un XML cu setări, dar niciuna nu îmi este la fel de la îndemână ca în cazul Thunderbird-ului. Enterprise FTW! Deci ca să-i dau într-un fel dreptate lui Freud, nu avem așa mare nevoie de oamenii ăia, cât de niște oameni cu adevărat competenți.
@Freud: auzisem de Costa Rica, dar nu știam prea exact ce și cum.
@Cristian : discursul pe care il aplici este tipic. Il aud de zeci de ori in discutiile intre "oamenii proiect" si "oamenii arhitectura " , intre "run" si "strategie" . Este "normal". Fiecare isi vede propria bucata de teren construita pe baza unui set de criterii care nu-s deloc comparabile . As putea spune ca a fost astfel adusa si o alta parte din raspunsul la intrebarea pusa in articol. Probabil ca bucatile de teren romanesti se cultiva fara a fi arate inainte . Foarte bine daca functioneaza . Asta nu inseamna ca cei ce au decis sa are au luat o decizie proasta .
@Freud Dar de ce nu-s meserii? Cum ai decis tu brusc ca nu-s? Stii exact ce se face, ai vorbit cu oamenii din domeniu, i-ai vazut la lucru?
@Cristian Cand zici de "problema", tu zici in fapt de o problema de comunicare, nu de una de meserie. Tu ii vezi pe practicantii meseriei cu pricina drept "probleme" pentru au alta perspectiva asupra softului decat tine si in concluzie normal ca exista un conflict daca nu reusiti sa vorbiti un limbaj comun si sa trageti in aceeasi directie.
@dana Referitor la ce se "stie", chestiunea e ca se stie in fapt doar la nivel de companii mari (venite din afara, gen Adobe) care practic vin cu toata organigrama, chit ca nu angajeaza musai in Romania la toate nivelurile. Dar dincolo de aceasta "stiinta" pur teoretica, nu se accepta ca ceva potential macar util in vreun fel. E celebra teorie cu "eu fac asa si asa e cel mai bine, ca stiu eu".
Deah, frec menta. Eu la birou as angaja un programator sa faca o baza de date si cel mult unul care preia hartii, nu nu stiu cate posturi de sef, hr, manager, administrator, secretar, cacaturi.
@Freud Mei, dar tu acum esti ca pensionarii care o dau mereu ca e pensia mica, indiferent de subiect. Ce-au a face posturile de sef, hr etc cu subiectul discutiei? Si la care birou zici tu ca ai angaja?
In sfarsit, ca fapt divers chestia cu "programator sa faca o baza de date" e de rasul curcilor, zau asa.
Eh, era legat de ce zicea dana, ca vezi d'le n-avem suficienti experti sugatori cafele pe facebook in birouri.
Pai daca secretarele sunt suficient de tampite cat sa nu stie excel, access, etc; platim pe unul sa le simplifice treaba cu un mdb cu meniu usor de introducere date, ceva gen.
Freud, dar Excel si Access nu sunt la capitolul baze de date, cam dupa cum o roaba nu-i nicidecum tren.
@Diana: de ce ești hateriță pe Excel și Access? Și oama e programatoare în FoxPro după unii sau în Cobol după alții și n-o urăște nimeni :-)
@dana, Diana: problema mea cu arhitecții ăștia care mi se bagă pe gât e modul în care complică lucrurile în mod inutil. Nu am nimic împotriva unei viziuni globale și de viitor, dar sunt pentru Benevolent Dictator For Life*, nu pentru indivizi care să-mi dea UML-uri cu ideile lor crețe.
Ca fapt divers, aș menționa că și la noi există posturi de Business Analyst de cel puțin vreo 5 ani pe la Vodafone și o băncă austriacă.
*Nu dau link că iarăși mă enervez.
Cristian, dar tu esti si impotriva UML imi pare? Ori mai exact a scopului UML, ca nu conteaza musai limbajul in sine.
Cat despre Vodafone si o banca austriaca, zic ca e fix ce-am zis anterior: "doar la nivel de companii mari (venite din afara, gen Adobe) care practic vin cu toata organigrama, chit ca nu angajeaza musai in Romania la toate nivelurile."
@Diana Coman: ideea din spatele UML-ului e bună, dar implementarea sau abuzul nu prea mai sunt.
Zi-i confirmare dacă vrei.
Pai intai ca de vreme ce ideea e buna inseamna ca cea mai buna implementare existenta e oricum mai buna decat lipsa oricarei implementari (ca doar e buna ideea in practica, nu in teorie, da?) Si pe de alta parte: ce abuz? Ce confirmare?
Așa nici eugenia nu e o idee rea, dar uite că atunci când au implementat-o naziștii n-a mai ieșit atât de bine. Abuz, adică exces de UML. Să stai să faci un UML pentru orice căcat când oricum naiba se va uita la el și peste câteva luni sau un an nici nu mai e valabil.
Confirmare la chestia aia cu Business Analystul.
@Cristian Cata vreme nu vii cu argumente concrete a propos de "nu e rea" eugenia ca idee, nu prea poti argumenta nimic pe tema. Faptul ca "are si niste beneficii potentiale" nu e in sine suficient ca sa spui ca "nu e rea ca idee".
Excesul de UML e rau, dar tu nu definesti in nici un fel excesul, ci pur si simplu decretezi ca Business Analystul face exces de UML si eventual ca reprezinta in sine (s-ar zice) un exces de UML. Ceea ce e fix apa de ploaie ca argument intr-o discutie despre utilitatea unei meserii ori chiar existenta ei ca meserie. Faptul ca n-ai nevoie de simulari pe calculator ca sa construiesti un cotet la caine nu inseamna ca simularile pe calculator sunt inutile, ori inexistente ca domeniu ori excese pur si simplu.
De atlfel articolul meu anterior fix asta spune: in Romania in IT se construiesc cam NUMAI echivalentul cotetelor pentru caine. Sigur ca n-ai nevoie de Business Analyst pentru asa ceva, ca nici business nu prea ai, clar.
Doar nu vroiai să scriu romane pe tema eugeniei. Eugenia e bună pentru că duce la îmbunătățirea speciei umane.
Aștept atunci exemple unde un Business Analyst și-a arătat valoarea, cu excepția băncilor și altor chestii financiar-contabile. Doar am dat exemple mai devreme unde n-a fost nevoie de așa ceva și nu poți spune că erau chiar cotețe de câine.
@Cristian Apa de ploaie. Ceva nu poate fi bun din cauza ca pretinde anumite rezultate prin definitie. Poate fi bun daca ori demonstreaza rezultatele cu pricina, ori le verifica empiric, ori macar produce niste rezultate dorite. Faptul ca pretinde ca ar produce asa ceva, nu are cum sa fie argument ca "e o idee buna".
Un sistem de monitorizare a traficului rutier pentru o primarie, o companie electrica, un spital, un soft pentru armata. Astea ti le zic din experienta directa. Altminteri insa un business analyst zic ca e util oricand chiar este un business (adica e mai complex decat poti tu venit din afara si programator mai degraba decat om de afaceri sa cuprinzi complet intr-o saptamana ori chiar ceva mai mult).
@Diana: la animale și plante aș spune că a dat roade eugenia.
Nu-s rele exemplele care le dai tu, dar sunt în continuare curios să văd cum s-au desfășurat lucrurile; cât de mult a ajutat, cât de mult a încurcat. În cazurile de mai sus, nu neg utilitatea unui om care să-ți explice ce e de făcut, doar că nu văd un om care doar compune emailuri cu tot felul de trăznăi. Mi-e greu să transpun în cuvinte ce am în minte. Într-un fel mă gândesc la băutorii de cafele de care spunea și Freud.
Am impresia că Edsger W. Dijkstra a zis la un moment dat (într-un interviu) ceva pe tema analiștilor și programatorilor, dar nu găsesc textul cu pricina.
@Cristian Mei, dar nu orice om caruia ii pui tablita cu Business Analyst chiar devine instant Business Analyst. De aia e acolo SFIA, ca sa vezi ce anume face in fapt respectivul. Deci daca vrei discutie despre utilitatea functiei (ori meseriei) trebuie sa mergi pe definitia ei, nu pe ce s-a intamplat sa vezi si sa pretinda ca ar fi. Nu de alta, dar altminteri vorbesti in fapt despre altceva.
La animale si plante cam ce rezultate bune a dat eugenia? Ca ai caini si pisici cu tot felul de probleme cronice? Ca ai porumb "foarte productiv" dar in esenta complet vulnerabil la toti daunatorii locali si eventual mai si distruge complet solul?
Sunt de acord cu distincția menționată de tine.
Cum era schema aia?
1. Breed
2. Plant
3. ???
4. Harvest
5. Profit
:-)
Ai dreptate cu faptul că unele rezultate nu sunt chiar atât de grozave pe cât se pretinde că ar fi. Plus că există riscul de a micșora varietatea de gene. Cum e totuși unele boli a căror șansă de apariție la copii crește dacă părinții sunt nu știu cum?
@Cristian Afirmatia ca "e buna" e foarte tare, in sensul ca in principiu orice problema poate sa o infirme. Chestiunea cu bolile si sansele e ca nu e foarte clar daca nu cresc si alte sanse. Altfel spus, e in fapt un subiect pe care se stie prea putin ca sa se poata veni cu idei bune la nivelul la care pretinde eugenia ca ar fi ca idee.
Si ce i-ar putea impiedica pe romani sa faca respectivele meserii gen "enterprise architect"? Cred ca oricum sunt mai multi care ar fi capabili sa fie arhitecti de-astia decat sunt posturi prin romania, deci nu vad unde e problema.
@Gheorghe La momentul actual ii "impiedica" faptul ca nu se pricep la chestiune pe bune. Nu e vreo piedica la modul ca "n-ar fi in stare" fizic/intelectual, ci una la modul ca a) nu are cine sa le-o ceara dat fiind ca majoritatea programarii in Ro e la nivel mai scazut pt care treaba cu pricina n-are sens si b) nu au habar cu ce se mananca pe bune.
Exista niste standarde ISO, IEEE sau mai stiu eu ce care specifica exact ce face si ce nu face un arhitect? Si mai rau, daca ipotetic ar veni un arhitect de-asta care nu stie sa faca pe bune si intamplator iese o treba mai buna decat a altuia care o face pe bune, cum s-ar reconcilia problema?
@gheorghe Lol, dar pe ce bazezi tu teoria cu vine unul care nu stie sa faca mai bine, da' in fapt face mai bine? Ca imi pare ca daca face mai bine, atunci se cheama ca chiar stie, nu?
Ceea ce contesti tu cu teoria asta ar fi calitatea standardului eventual, atata doar ca daca nu o faci concret pe un standard anume, n-ai facut nimic si n-are sens contestatia. Dar in general asta e teoria celor care nu pricep la ce foloseste un arhitect - ca "oricum fac eu mai bine chiar daca nu-s arhitect, ca n-am eu nevoie de nu stiu ce standarde (pe care altminteri nu le cunosc, dar na)."
Inca o data, ca-i important: daca ai de scris un modul de 2000 de linii de cod, chiar n-ai nevoie de arhitect, ca-i cam overkill. Si similar daca repari buguri ori faci in fapt bucatelele pe care le-a proiectat altcineva in alta parte. Da' sa ai senzatia aca asta e toata programarea si deci "nu-i nevoie de arhitecti" e doar dovada de nestiinta, nimic mai mult.
[...] atunci, pentru că nu aveam acces la nici o altă hartă gata făcută, pentru că la noi lumea pare să fie încă absolut convinsă că hărțile sunt inutile – [...]