Cum Se Construieste Un Produs PDF

Cum s construieti un
produs IT
erban r
Sergiu Damian
Silviu Dumitrescu
Zsolt Polgar
Victor Ionescu
Voicu Oprean
Andreea Prvu
Sebastian Big
Diana Ciorba
Monica Soare
Cluj-Napoca, 2014
Dan Suciu
Peter Lawrey
Silvia Rusanu
Simona Bonghez
Mircea Vdan
Bogdan Rus
erban Meza
Zornitsa Tomova
Alexandru Bolboac
Today Software Magazine
Cum s construieti un produs IT

Aceast carte a fost lansat n cadrul evenimentului Cluj IT Days 2014 i
va fi disponibil online gratuit pe site-ul www.itdays.ro.
Un proiect de promovare a mediului IT romnesc i a valorilor acestuia.
Cum s construieti un produs IT

erban r
Voicu Oprean
Peter Lawrey
Sergiu Damian
Silvia Rusanu
Simona Bonghez
Sebastian Big
Mircea Vdan
Zsolt Polgar
Diana Ciorba
Zornitsa Tomova Victor Ionescu
Alexandru Bolboac
Dan Suciu
Andreea Prvu
Silviu Dumitrescu
Bogdan Rus
erban Meza
Monica Soare
Redactor: Ovidiu Man

Coordonator: Ovidiu Man
Coperta: Ovidiu Man
Copyright: Emilia Man
Tehnoredactor: Ovidiu Man
Corector: Emilia Man
Traductor: Roxana Micu
Tiprit la Antoma Advertisment
Today Software Magazine, 2014
ISBN 978-973-0-17970-5
Produs de
Today Software Solutions SRL
str. Plopilor, nr. 75/77
Cluj-Napoca, Cluj, Romania
contact@todaysoftmag.com
www.todaysoftmag.ro
www.todaysoftmag.com
www.itdays.ro
CUPRINS
INTRODUCERE

CLUJUL - SILICON VALLEY

TIPARE DE GNDIRE N ANTREPRENORIAT

O METOD STRUCTURAT DE LUCRU PENTRU STARTUP-URI
UN PRIM PAS N DEZVOLTAREA UNUI PRODUS

CUM PUTEM GNDI INTERACTIV USER EXPERIENCE-UL?
PRIVIND CU OCHII UTILIZATORULUI FINAL

MANAGEMENTUL PRODUSELOR PENTRU STARTUP-URI
ARHITECTUR PENTRU STARTUP-URI. PROVOCRI I DECIZII.
SUB PRESIUNEA BIG DATA

TENDINE DE EVOLUIE A COMUNICAIILOR SPRE
INTERNETUL VIITORULUI
PLATFORMA DE CONECTIVITATE PERMANENT PENTRU
TRANSPORTUL PUBLIC INTELIGENT
E-EDUCAIE I PLATFORME EDUCAIONALE ONLINE
JAVA STANDARD 8, NOUTI I MBUNTIRI
CHRONICLE MAP AND YAHOO CLOUD SERVICE BENCHMARK
TENDINE N DEZVOLTAREA DE SOLUII ENTERPRISE
ESTUL NTLNETE VESTUL INTELIGENA CULTURAL
N PROIECTE
DESPRE ANGAJAMENTE N PROIECTE AGILE

MANAGEMENTUL ECHIPELOR VIRTUALE
JOCUL RECRUTRII

9
13
19
27
37
43
51
61
75
83
95
111
123
129
155
161
167
177
185
193
CUM SE CONSTRUIETE UN PRODUS IT
Cuvnt nainte
IT-ul romnesc a cunoscut o evoluie constant n ultimii cincisprezece

ani. Am nceput cu atragerea proiectelor de outsourcing i dezvoltarea companiilor locale. Succesul a aprut repede, iar Clujul s-a remarcat printr-un
numr mare de specialiti bine pregtii graie celor dou universiti locale.
Outsourcing-ul s-a transformat gradual, trecnd de la un sistem n care project
management-ul era exclusiv strin la un mai mare ownership pe proiecte i
la o delegare a ntregilor responsabiliti de dezvoltare a produselor la nivel
local. Numrul mare de specialiti de top pe care i are Clujul demonstreaz
o cretere consistent a nivelului de pregtire tiinific. Aceast evoluie
rapid precum i o oarecare nesiguran n viitorul outsorcing-ului a generat pe piaa romneasc i n particular pe cea clujean o nevoie acut de
creare a unor produse locale. n momentul de fa, majoritatea companiilor
experimenteaz diverse soluii i variante de aciune menite s transforme
aplicaiile proprii n produse locale de succes. Este un demers dificil, la a
crui reuit i dorete s contribuie i cartea de fa. De altfel, titlul ales,
Cum se construiete un produs IT, transmite tocmai aceast intenie de a oferi
o surs de inspiraie pentru companiile locale, pentru tinerii antreprenori i
programatori. Miza acestei cri este de a reda o imagine ct mai complet
asupra componentelor eseniale din ecosistemul antreprenorial: experiena
acumulat n dezvoltarea de produse, inovaia reprezentat prin proiectele de
cercetare i execuia prin seciunea tehnic i cea de management. Apariia
acestei lucrri este o completare a conferinei Cluj IT Days 2014, itdays.ro,
acordat participanilor ca o ocazie de aprofundare a subiectelor abordate i
10
ca un impuls pentru noi i inedite subiecte n alte viitoare ediii. De altfel,

majoritatea celor prezeni pe scen sunt vechi colaboratori ai revistei noastre,
Today Software Magazine1.
Totodat, cartea va fi disponibil online gratuit, dnd astfel posibilitatea
i celor care nu au fost prezeni la eveniment s descopere o parte dintre subiecte i s i ajute n dezvoltarea viitoarelor produse de succes.
Dar, nainte de toate, avem nevoie de curajul de a realiza lucruri noi. i
pentru acestea contm pe tine, cititorule! Dac n aceast ediie n seciunea
de leadership se vorbete despre cum s tranziionm de la outsourcing la produs, sperm ca n ediia din 2015 a Cluj IT Days s vorbim mai mult despre
produse dezvoltate local.
Mult succes n dezvoltarea de produse IT noi !!!
Ovidiu Man
1
www.todaysoftmag.ro i www.todaysoftmag.com
Voicu Oprean
Voicu Oprean este un antreprenor concentrat pe dezvoltarea i distribuirea

soluiilor software pentru web, mobile, ncorporate i cloud, cu o experien
vast n outsourcing pentru industria de turism i ospitalitate. El a nfiinat
AROBS Transilvania Software n iunie 1998, cu obiectivul principal de a
promova specialitii software IT romni i de a le oferi oportuniti frumoase
de carier n Romnia. AROBS Transilvania Software are n prezent peste
350 de specialiti angajai; compania are birouri operaionale n Cluj-Napoca, Bucureti, Iai, Trgu Mure, Timioara, Chiinu i Londra.
1
IT-UL: SIMPLE CIFRE SAU PUTEREA DE A

SCHIMBA COMUNITI?
Clujul a devenit Silicon Valley-ul Europei, unde, conform estimrilor
publicaiei Paris Match, aproximativ 20.000 de specialiti n IT dezvolt produse menite s-i dea omului libertatea, sigurana i confortul de care are
nevoie. Dac pn nu de mult piaa local de IT era bazat preponderent
pe outsourcing, adic pe servicii prestate pentru clienii din strintate, acum
inginerii software clujeni nu doar c le vin n ntmpinare clienilor cu soluii
i produse menite s le creasc businessurile, dar ncep s se alinieze misiunii
generale de a inova n beneficiul societii, contribuind la dezvoltatea unei
industrii vitale pentru toate sferele vieii.
Datorit prezenei facultilor cu profil informatic i migraiei specialitilor din alte orae ale rii, piaa de IT din Cluj dispune de o resurs uman
preioas, dar care este dominat de o concuren acerb, n care companiile
se zbat s atrag pe cei mai talentai oameni.
ns provocarea real nu ar trebui s fie cursa pentru cei mai buni oameni, indiferent de costuri, ci evoluia industriei i implicit a mediului n care
trim. Acumularea cantitativ a determinat saltul calitativ n IT, iar acum
companiilor le revine misiunea de a se concentra pe dezvoltarea unor produse inovatoare. Aceste produse care ar putea s se impun la nivel global
sunt cele care pe termen lung vor face diferena.
14
n definitiv, rolul nostru, al IT-tilor este de a mica lucrurile, de a optimiza procese, de a reduce costuri i a mbunti n egal msur activitile
cotidiene ale oamenilor de rnd i ale mediului de afaceri.
EVOLUIA. DE LA OUTSOURCING LA PRODUS

La fel ca alte companii de profil, AROBS i-a fcut intrarea pe pia cu
servicii de outsourcing, consolidndu-i poziia datorit credibilitii acumulate n timp i competenei oamenilor implicai. Dar nu ne-am oprit aici,
ci am trecut la un alt nivel odat cu dezvoltarea unor produse cu valoare
adugat mare, care au ntrit brandul i au adus beneficii palpabile utilizatorilor.
n 2003, am lansat Optimall SFA, un produs de automatizare a vnzrilor,
care ajut n momentul de fa peste 3.000 de ageni de vnzari i de mercantizori s i optimizeze activitatea i s-i creasc controlul n relaia cu
clienii lor din diverse zone ale rii.
n 2006, am lansat soluia de monitorizare a parcului auto TrackGPS,
utilizat de peste 2.000 de clieni, pe mai mult de 30.000 de maini. A mai
fost i soluia pentru automatele de bilete de transport n comun. Un ntreg
municipiu Iai, capitala Moldovei folosete acest produs i sunt convins
c acesta este doar nceputul.
Manualele digitale pentru copiii din clasele I-II-a sunt un alt produs
de care suntem foarte mndri, pentru c avem convingerea c, n acest fel,
putem contribui la educaia viitoarelor generaii i la dezvoltarea nvmntului romnesc, aflat n picaj n ultimii ani.
Pe lng produsele de mai sus, pe care le considerm vrfuri de aisberg,
AROBS are i alte produse incubate, care vor fi lansate n lunile ce urmeaz.
Toate sunt rezultatul a sute de ore de creaie, agitaie i nesomn, dar i
rspunsul la micile eecuri crora a trebuit s le facem fa de-a lungul timpului. Pentru c nu orice inovaie devine automat vital pentru utilizatori, a
trebuit i noi s trim pe pielea noastr experiena dezvoltrii multor produse
care nu au reuit s intre n topul preferinelor consumatorilor. Dup ce am
creat o soluie pentru ageniile de turism, care a convins doar zece clieni i
nc una pentru gestionarea charterelor de ctre tur-operatori, a trebuit s
acceptm acest rezultat sub ateptri i s ne orientm spre alte produse, prin
care s intim direct nevoile beneficiarilor.
16
nc de la nceput, visam la o companie complet, de aceea dup outsourcing i soluiile software, pasul firesc era s dezvoltm produse hardware. Aa,
am nceput fabricarea n mas, n China, a produselor sub brandul Smailo.
Acesta include primul sistem de navigaie din Romnia- un brand 100%
romnesc, tablete Android, camere auto DVR i actioncamera, foarte preuite
de amatorii de sporturi extreme de la scufundri pn la sriturile cu parapanta.
Noi, la AROBS ne ghidm dup o filosofie pe ct de simpl pe att de

benefic: ncurajarea inovaiei i a spiritului antreprenorial. Pornind de aici,
n ultimii ani, ne-am axat pe creterea calitii i a cantitii produselor pe
care le livrm n tandem cu dezvoltarea capacitilor angajailor, prin implicarea lor n proiecte internaionale. Experiena acumulat n acest fel o
transpunem ulterior n proiectele interne, fapt ce favorizeaz inovaia i lansarea pe pia a unor produse create de oameni pentru oameni. Fr ndoial,
o greutate mare n procesul de creaie l are i background-ul lor informaional
i cultural din echipele noastre fac parte astzi specialiti romni, maghiari,
olandezi, coreeni, irlandezi sau basarabeni -, astfel c produsele scoase pe
pia de AROBS le dau un sentiment de diversitate i universalitate celor
care le aleg.
Trim ntr-un ora n care IT-ul a devenit noua industrie grea a secolului. Clujul ne-a pus la dispoziie resursele sale, iar acum e timpul ca noi s
ne punem n slujba comunitii, oferindu-i, n schimb, produse i servicii de
nalt calitate, performante i inovatoare.
AROBS i-a asumat deja acest rol, dar voi? Ce-ar fi dac, n 2015, fiecare
companie ar lansa cel puin un produs cu valoare adugat? Orice drum ncepe cu primul pas, spune un vechi proverb. Aa c de ce nu ar face fiecare
dintre noi acel pas ca s schimbm faa comunitii?
Doar n acest fel lansnd produse inovative, Clujul va deveni un adevrat
Silicon Valley!
Dac i-am urma sfatul lui Tony Hsieh, fondatorul Zappos - Distrai-v!
Jocul e mult mai savuros atunci cnd ncerci s faci i altceva, nu doar bani -, am
construi pies cu pies o lume mai bun. n definitiv, ceea ce lsm dup noi
este mai presus de orice strategii de moment.
Autor
Voicu Oprean CEO @ Arobs
erban r
erban r are o experien de 14 ani n lucrul cu companii avnd baza n

Silicon Valley. n aceast perioad a jucat roluri diferite n cadrul proiectelor
software n care a fost implicat, ncepnd de la dezvoltator software pn
la Vice Preedinte n Inginerie. Experiena sa include relaii de afaceri att
cu startup-uri mici, ct i cu companii publice foarte mari. n prezent, este
CTO al grupului de companii Gemini Solutions.
El a neles valoarea real a inovaiei tehnologiei de vrf i este unul dintre
iniiatorii Gemini Foundry, un accelerator flexibil care promoveaz startup-urile high-tech romneti pe piaa american.
2
TIPARE DE GNDIRE N
ANTREPRENORIAT
O INCURSIUNE N MEDIUL ANTREPRENORIAL DIN
ROMNIA
ECOSISTEMUL ANTREPRENORIATULUI
ROMNESC
n Romnia, antreprenoriatul n sine presupune o gndire disruptiv dac
lum n calcul istoria ultimilor ani. nainte de revoluia din 1989 nu se putea
vorbi de antreprenoriat pe teritoriul rii noastre, iar n cei 25 de ani ce s-au
scurs de atunci multe dintre tentativele antreprenoriale high tech au falimentat rapid fie din cauza dezinteresului general n a susine astfel de iniiative,
fie din cauza puterii reduse de cumprare sau de a investi .
Dac dorim s ne concentrm pe domeniul IT, numrm pe degetele de
la o mn antreprenorii ce au pornit din Romnia i au nregistrat un succes
pe plan global. n plus, salariile din mediul IT ofer celor care le primesc o
plas de siguran care face trecerea ctre antreprenoriat cu att mai grea i
netentant. Antreprenoriatul n sine poate fi asemnat cu un salt dificil la
trapez fr plas de siguran: cine reuete, culege toi laurii, iar cine nu
De aceea, considerm c antreprenoriatul n Romnia presupune o gndire disruptiv, o ieire din tipare, un NU ferm spus vieii de salariat i o
dorin acerb de a i lua destinul n propriile mini. n ultimii ani ns
observm c acest curent ncepe s prind n rndul tinerilor care sunt din ce
n ce mai dornici s nvee cum pot deveni proprii stpni. Lor le dedicm
acest articol.
Presupunem c suntei un tnr antreprenor n IT, eventual parte a unei
echipe ce are o idee n care crede cu trie i suntei gata de a renuna la co-
20
moditatea vieii de angajat ntr-o corporaie, pentru a-i vedea visul realizat:
La ce ar trebui s v gndii? Ce ntrebri ar trebui s v punei?
Mai jos ncercm s trecem prin cteva dintre ele. ntmpltor sau nu, n
mare coincid cu punctele pe care un eventual investitor (fie el instituional
sau privat, VC sau business angel) vrea s le aud pentru a lua n calcul o
investiie. Ele constituie scheletul a ceea ce se numete pitch ctre un investitor.
Pentru a face lucrurile mai uor de neles, ne propunem s condimentm
explicaiile tehnice cu exemple de aa nu, parte dintre ele gustate n practic.
Acest articol nu se vrea unul critic la adresa mediului antreprenorial
romnesc, care a evoluat mult n ultimii ani. Greelile subliniate sunt destul
de des ntlnite i pot fi evitate uor cu puin atenie. Se vrea aadar un
ndrumar/ajutor venit n ntmpinarea celor care-i construiesc pitch-ul i se
pregtesc s atrag o investiie.
SUBIECTE LEGATE DE BUSINESS MODEL

Modelul de business este un termen amplu care descrie modul n care
o organizaie creeaz i livreaz o plus-valoare. Acesta definete aspectele
cheie ale unui business, precum scop, infrastructur, structuri organizaionale, procese utilizate, public int i multe altele. ns, dac anumite puncte
ale acestui model pot fi dezvoltate ntr-o etap ulterioar, fiecare antreprenor
ar trebui s trateze de la nceput cu seriozitate urmtoarele aspecte:
Valoarea adugat (value proposition) const ntr-o descriere simpl,
scurt i uor de neles a ceea ce este businessul / serviciul pe care l oferi: Ce
21
oferi, ce nevoie adresezi i de ce ar cumpra cineva de la tine?

Difereniatori cheie (key differentiators) - Ce te deosebete de ceilali de
pe pia, de concuren ? n literatura de specialitate avem teoretic de ales
ntre cteva variante, bine delimitate. Sau poate, n cazul cel mai complex,
ntre combinaii ale lor.
Unfair competitive advantages orict m-a strdui mi-e greu s traduc
acest termen. Poate: avantaje ce provin dintr-un start furat. Mai simplu
spus: ce ai ai n mn pentru ca altcineva s nu fac acelai lucru ca tine. Fie
mai repede, fie mai bine. De ce o corporaie care are resurse mult superioare
ie, nu i-ar lua-o nainte, eventual cu un produs mai bun.
Dac, n general, primele dou subiecte sunt puse n eviden, cel deal treilea pare tabu pentru antreprenorii autohtoni. n rare cazuri am auzit
pomenindu-se fie i cteva cuvinte despre el.
NDA
Vom prezenta ceea este NDA i n ce const semnarea unui NDA. Am
auzit de attea ori Am o idee grozav, i-o voi spune dup ce semnm un
NDA ca s fiu sigur c nu mi-o furai. S furm ce? O idee? Atenie! NDAul este menit s protejeze un business n sine cu specificul i difereniatorii
lui i nu o idee sau o ni de pia. Ca s nu mai adaug c investitorii serioi
nu semneaz NDA.
ANALIZA DE PIA
TAM VS. SAM VS. SOM
Evident c orice antreprenor trebuie s-i neleag piaa n cele mai mici
detalii. n plus fa de aceasta, care este o pre-condiie a succesului unei iniiative antreprenoriale, n cazul n care antreprenorul vrea s obin finanare,
acesta trebuie s tie crei piee se adreseaz. Realitatea arat ns destul de
des confuzii legate de piaa total adresabil i de segmentul pe care sper
antreprenorul s-l obin din aceast pia.
Pentru o mai bun nelegere a acestor noiuni recomandm citirea urmtorului articol explicativ: https://www.thebusinessplanshop.com/blog/en/entry/
tam_sam_som
22
COMPETIIE
Se pare c n Romnia, afirmaia Noi nu avem competiie real este
foarte frecvent asimilat unei stri de fapt care continu s persiste n mediul
antreprenorial. Fii foarte reticeni n a spune acest lucru! Dac nu ai avut
cumva o idee absolut genial (una la un miliard) atunci acest fel de aseriune ascunde o insuficient cunoatere a pieei.
Iat mai jos capitolele care ar trebui atinse ca parte a analizei competiiei:
Ofer altcineva o soluie la problema pe care o rezolvi?
Sunt muli competitori sau civa juctori care controleaz piaa?
Ce oferi tu diferit de acetia? Cu ce eti mai bun fa de ceilali?
Dac o alt companie a ncercat s rezolve aceeai problem, dar a
euat. Care au fost cauzele acestui eec? Ce s-a ntmplat? Unde a
greit? De ce a euat?
POTENIAL DE CRETERE I
SCALABILITATE
Este foarte important de neles c pentru investitorii n high-tech, potenialul de cretere al businessului primeaz n faa unei surse imediate de
venit. Ei i asum faptul c investiiile n startup-uri din zona IT sunt investiii de risc ridicat. Tocmai de aceea in foarte mult ca n cazul unei reuite
aceasta s fie de magnitudine ridicat. n plus, este mult mai uor s creti
profitul obinut dect s atragi utilizatori noi n aplicaie sau s i menii pe
cei deja existeni.
Dei muli dintre antreprenori tiu, subliniem i noi c pentru investitori
este mult mai important ca afacerea s aib un potenial de cretere, scalabilitate mare, dect obinerea unui break-even rapid / venituri imediate.
CLIENI
n general un startup rezolv o problem care i este familiar fondatorului su. Lovindu-se deja de acea problem, fondatorul poate da o direcie iniial n sperana c alte persoane, care s-au lovit de aceeai problem, i se vor
altura n utilizarea produsului / serviciilor oferite. Din acest moment este
23
foarte important ca startup-ul s asculte feedback-ul clienilor pentru a gsi o

direcie de dezvoltare favorabil i a nu cdea n capcana: Eu am problema
asta, doar eu tiu ce e mai bine s fac acest produs. n modul acesta clienii
se ntorc ntr-o aplicaie pe care o gsesc pe placul lor i pot atrage dup ei
ali poteniali utilizatori.
De aceea, cnd vorbim de clieni este foarte important s avem n vedere
urmtorii indicatori:
STRATEGII DE ACHIZIIE I COSTURI
Care vor fi primii pai n atragerea utilizatorilor? Vorbeti cu prietenii,
utilizezi reelele sociale, forumuri, etc.? Aceste strategii trebuie puse n balan n funcie de costurile angrenate (timp/bani) i numrul potenial de
clieni pe care l poi atrage.
Un topic care lipsete foarte des din analiza antreprenorilor locali se refer
la achiziia a ceea ce se numete early adopters - adic utilizatori timpurii
ai produsului. Auzim prea des expresii de genul dup ce voi avea zece mii de
utilizatori, se va propaga viral. n lipsa unei strategii adecvate de atragere a
utilizatorilor timpurii, este posibil s nu ajungei nici mcar acolo. Utilizatorii timpurii sunt de regul cei mai greu de atras.
TRACIUNE I RETENIE
Traciunea este un indicator foarte important i n principiu reprezint
dovada c piaa este interesat de ceea ce construieti tu, deoarece are nevoie de acel produs. Este important s aduci mereu utilizatori noi i s-i transformi n clieni fideli. Altfel, toate investiiile pe aceast parte vor fi n zadar.
Vei avea ntr-adevr foarte muli utilizatori, dar care nu se mai ntorc a doua
zi.
Cel mai adesea aceasta nevoie a pieei se msoar la modul concret pentru site-urile web de exemplu n utilizatori unici, numr de utilizatori noi
n comparaie cu utilizatorii care au prsit platforma, numr de utilizatori
activi etc. . Subliniem ns c traciunea (mpreun cu diversele mrimi care
o pot msura) nu este singurul mod n care se poate evalua valoarea unui
business.
PROPRIETATE INTELECTUAL I PATENTE
Un exemplu simplu de neles este cel legat de un produs care are
pri, algoritmi, idei patentabile. Cu ct numrul de posibile patente este mai
24
mare cu att evaluarea crete. De asemenea crete i ncrederea investitorului

c produsul / serviciul nu poate fi copiat.
MONETIZARE
Am menionat anterior c potenialul de cretere primeaz n faa obinerii unor venituri imediate. Acest lucru ns nu nseamn c monetizarea nu
trebuie s v mai preocupe deloc. Este indicat s avei un plan de a obine
nite venituri de pe urma produsului / serviciilor oferite, chiar dac acest
lucru se va ntmpla dup ceva timp.
ECHIPA
Echipa este sufletul fiecrui startup, totodat i principalul factor luat n
considerare de un potenial investitor atunci cnd acesta hotrte s investeasc. Aceasta se datoreaz faptului c dup ce va face investiia se presupune
c va petrece suficient timp cu membrii echipei sau cel puin cu liderul ei.
Trebuie s se simt relaxat i ncreztor pentru a petrece acest timp. Vom
detalia n rndurile urmtoare atuurile unei echipe.
DE CE NOI?
Ce anume difereniaz aceast echip de altele?
De ct timp lucrai mpreun?
Proiectele trecute dezvoltate mpreun cu echipa sunt un bonus - chiar dac ele nu au mers ideal. Orice eec este o lecie nvat.
Echipa nu va mai trebui s treac de obstacolele pe care le ntmpin
n perioada de formare cnd fiecare i gsete un rol i nva s lucreze cu ceilali membri.
EXPERIENE COMPLEMENTARE
Echipa ideal este compus din trei membri cu experiene complementare: o persoan tehnic, o persoan cu experien de business i una n marketing, eventual design. Fiecare persoan trebuie s aib rolurile foarte bine
definite i s i cunoasc responsabilitile. Aceasta nu nseamn c echipe
formate din dou sau patru persoane nu pot reui ntr-un startup. Dar conteaz ca membrii echipei s fie experi pe arii diferite.
25
TOAT LUMEA ARE CUNOTINE
Trim ntr-o lume n care chiar conteaz pe cine cunoti. Dei meritocraia nu caracterizeaz nc foarte mult societatea noastr, acest lucru nu
trebuie s ne sperie. Persevernd vom putea crea condiiile instaurrii unei
meritocraii. Cu ct vei nelege mai repede regulile jocului cu att le vei
putea folosi mai repede n avantajul vostru. Ducei-v la conferine, facei
networking i cretei-v cercul de cunotine.
Punei-v n locul unei persoane care ntlnete zilnic zeci de echipe, fiecare cu cte o idee genial i o promisiune de a schimba lumea. Cum faci
diferena ntre cei care vnd iluzii i cei care chiar pot duce visul pn la
stadiul de realitate? ncepi s favorizezi echipele care vin cu referine de la
oameni n care ai ncredere. Dac una sau mai multe persoane din cercul tu
de cunotine recomand pe cineva, priveti cu ali ochi acea echip.
SINDROMUL ANTREPRENORULUI CU
JUMTATE DE NORM
Unul dintre cele mai des ntlnite scenarii este urmtorul: Am un proiect
la care lucrez n timpul liber. Dou ore pe zi i uneori n weekend. Aceasta
poate fi o soluie pe termen scurt, mai ales n ceea ce privete primii pai,
ns pe termen lung este doar o cale sigur ctre eec. Un startup nu ar trebui
s fie acel lucru pe care l faci cnd gseti puin timp liber sau cnd vii deja
obosit dup o zi de munc. Pentru a avea succes va trebui s fii implicat 100%
n startup-ul tu deoarece obstacolele pe care le vei ntlni vor avea nevoie
de toat atenia ta, iar la sfritul zilei aceasta va face diferena ntre cei care
reuesc i cei care rmn n urm.
Cu acest articol ne reafirmm ideea c mediul antreprenorial romnesc
a evoluat mult n ultima perioad i este n continu evoluie. O problem
este nc lipsa de pe piaa autohton a caselor de venture capitalists, dar i n
acest caz credem c este doar o chestiune de timp.
Odat acest ecosistem format din antreprenori-incubatoare-investitori, nu va mai fi mult pn vom vedea startup-uri romneti de real succes
pe pieele globale. Trebuie doar rbdare.
Autori
erban r CTO, Gemini Solutions
Radu Popovici - Associate, Gemini Solutions Foundry
Alexandru Bolboac
Sunt un dezvoltator de software pasionat, o persoan care nva continuu,
mentor i profesor la Mozaic Works. Sunt un programator poliglot, iubesc
provocrile i utilizez toate tehnicile pe care le cunosc pentru a le depi. De
anul trecut, dezvolt i produse.
Cteva informaii despre mine:
Am facilitat primul Code Retreat n afara Statelor Unite (cu Maria Diaconu) i am ajutat la definirea formatului.
15 ani de dezvoltare software
5 ani de C++
7 ani de C#
5 ani de predare, mentorat i instruire
Iubesc arhitectura software, designul, programarea. n prezent nv
cum s creez produse extraordinare.
Am ajutat la crearea comunitilor AgileWorks n ase orae mari din
Romnia.
Nu ezitai s m contactai pentru sfaturi, programare n pereche (chiar
i la distan) sau oportuniti de dezvoltare n acest domeniu, pe website-ul
meu http://alexbolboaca.ro sau prin Mozaic Works http://mozaicworks.
com.
3
O METOD STRUCTURAT DE LUCRU
PENTRU STARTUP-URI
Dezvoltarea unui produs implic mult efort, nelegere i adaptare la realitile pieei. Datorit modificrilor multiple, presupunerea antreprenorilor
este c abordarea f orice e posibil e suficient. Dei dezvoltarea unui produs este o activitate care se desfoar la limita haosului, ea poate fi realizat
ntr-un mod controlat i ordonat.
Iat un model simplificat:
Clarificarea unui scop i a unei viziuni.
Validarea viziunii prin experimente.
Iterat de la 1 (fie clarificarea i mai detaliat, fie pivotare).
Pentru validarea viziunii, urmtoarele unelte pot fi folosite:Identificarea MVP-ului folosind Personas i Storymapping,
Planificarea implementrii folosind user stories,
Identificarea presupunerilor i a experimentelor necesare,
Folosirea Kanban pentru o abordare disciplinat a dezvoltrii,
Utilizarea ATDD i a mockup-urilor pentru a elimina ct mai mult
din necunoscut.
Fiecare dintre tehnicile menionate mai sus este detaliat n rndurile
urmtoare.
28
SCOP I VIZIUNE
Totul pornete de la un scop i de la o viziune asupra produsului. Nu voi
insista mult pe aceste subiecte, pentru c s-au scris nenumrate articole i
cri despre ele. Merit totui reamintite cteva aspecte cheie.
O viziune bine definit ajut la luarea rapid a deciziilor n timpul dezvoltrii produsului i a businessului. Dei ne-am dori s lum toate deciziile
ntr-un mod bazat pe date, realitatea este c rareori un business poate atepta
momentul n care toate datele sunt clare i corect interpretate. Aproape orice
decizie de business se ia pe baza unor informaii pariale. n lipsa informaiilor complete, alte elemente conteaz pentru luarea deciziilor: intuiia
echipei i a antreprenorului i mai ales viziunea produsului.
Viziunea do no evil a Google este clar definit n filozofia companiei1:
Nu permitem ca anunurile publicitare s fie afiate pe paginile noastre de rezultate, dect dac sunt relevante acolo unde apar.
Noi credem c publicitatea poate s fie eficient fr a fi iptoare.
Publicitatea pe Google este ntotdeauna marcat clar drept Link
sponsorizat, astfel nct s nu compromit integritatea rezultatului
cutrii noastre.
Scopul produsului este diferit de viziune. Dac viziunea se refer la filozofia produsului, scopul este msurabil. Acesta poate fi legat de: numr de utilizatori, venituri, numr de vizite, etc. .
Lucrez n acest moment la un produs eHealth. Viziunea lui este s ajute actul
medical al medicilor de familie pentru a preveni greelile i a simplifica partea administrativ. Scopul pe care ne concentrm n acest moment este s reducem timpul
petrecut de doctor n medie cu introducerea datelor pacienilor. Viziunea este greu
de msurat, scopul l putem msura prin compararea cu alte aplicaii similare.
TEHNICI UTILE
PERSONAS
Noiunea de persona provine din comunitatea UX. O persona nu este altceva dect un profil de utilizator, care ofer contextul necesar pentru experimente i alegerea funcionalitilor. Profilul de utilizator poate fi mbogit
1 https://www.google.com/about/company/philosophy/
29
incremental.
Nume: Dan2
Specializare: Doctor de Familie
Vrst: 36 ani
Familie: Necstorit
Alte detalii:
deine o tablet i un iPhone
are cont pe Facebook
i face concediile n strintate
Personas pentru un produs pot fi identificate de echip printr-un workshop de cteva ore.
E important de neles c i personas implic presupuneri legate de produs
i de utilizatori. E bine ca aceste presupuneri s fie pe ct posibil validate, fie
prin statistici demografice fie prin interviuri cu poteniali utilizatori.
STORYMAPPING
Storymapping este o tehnic de a identifica paii necesari pentru ndeplinirea unei activiti, din punctul de vedere al utilizatorului. Fiecare pas poate
fi ndeplinit n mai multe moduri fie n aplicaie, fie n afara ei.
Exemplu de storymap pentru prescrierea unui medicament:
Selectare medicament -> Stabilire doz -> Indicaii administrare -> Imprimare prescriere
Text liber
Cutare medicament
Cutare subst. activ
Cutare clas medicamente
E bine ca echipa s porneasc de la identificarea scenariului complet, urmnd ca apoi s selecteze ce anume va fi implementat i ce anume pare
a oferi cel mai mare beneficiu pentru utilizator. Cu ct sunt implementai
mai repede paii care aduc valoare pentru utilizatori, cu att cresc ansele de
conversie rapid.
2
Sursa imaginii: http://pixabay.com/p-217140/
30
USER STORIES
User story-ul este cea mai rspndit modalitate de gestionare a cerinelor
din Agile (XP, Scrum) i Lean/Kanban. Avantajul unui user story fa de
documentele de cerine este c permite rafinarea incremental a cerinelor
pe msur ce echipa nelege mai bine utilizatorii i piaa.
User story-ul este i un element de dialog ntre utilizatori, programatori,
designeri i testeri. n cea mai simpl form a sa, un user story arat astfel:
Ca un <rol> vreau s <aciune> astfel nct <beneficiu>
De exemplu:
Ca medic de familie vreau s gsesc un medicament pe baz de nume
astfel nct s l pot prescrie rapid
User story-ul este ns foarte adaptabil i permite modificri sau adugarea unor elemente de care au nevoie fiecare din cei implicai n produs. De
exemplu:
Un mockup va permite programatorilor s nceap rapid implementarea i va asigura integritatea designului grafic.
Teste de acceptan vor permite validarea complet a user story-ului i
implementarea sa corect.
Informaii suplimentare pentru deployment, n cazul n care exist
probleme specifice.
n cazul utilizrii personas, user story-ul se poate referi la o persoan n
loc de un rol. Acest lucru ajut la ajustarea sa n funcie de profilul utilizator.
Cum se schimb user story-ul de selectare medicament pentru a converti utilizatorul urmtor?
Nume: Grigore3
Specializare: Doctor de Familie
Vrst: 53 ani
Familie: Cstorit, doi copii
Alte detalii:
puin familiarizat cu tehnologia
scrie la tastatur foarte ncet
are nevoie de ochelari pentru citit
3 http://whatisstomachflu.com/wp-content/uploads/Senior-medical-doctor-Large.jpg
28-29 May 2015, Bucharest

The only technology agnostic unconference in Central and Eastern Europe! Participants will find
out new concepts and ideas, will learn new techniques and enjoy the company of practitioners
from all over Europe at the 3rd I T.A.K.E Unconference edition - http://itakeunconf.com
The schedule includes sessions on Architecture, DevOps, Product Development, Technical
Leadership or Hardcore Programming. During OpenSpace you get the chance to be a speaker
yourself and to include in the program the topics you are interested in.
HOW IS IT SPECIAL?
Top 4 reasons: 1) Its technology agnostic, so you will learn no matter what you code in at work. 2)
You get to meet leading software craftsman from Europe and USA. 3) Talks are only 25% of the
event, the rest is hands-on work. 4) Its small enough that you can talk to virtually everybody.
WHO WILL BENEFIT THE MOST?
The main audience: Craftsmanship Programmers, Architects, DevOps, Technical Leaders,
CTOs and Managers, Technical Co-Founder, Technical Consultant.
FIRST CONFIRMED KEYNOTES
Simon Brown is an award-winning speaker and author of Software Architecture for Developers - a
guide to software architecture, technical leadership and the balance with agility.
James Lewis introduced evolutionary architecture practices and agile software development techniques to various blue chip companies.
REGISTRATION
Registration is now open at http://2015.itakeunconf.com/register
For any questions: alexandra.marinescu@mozaicworks.com
32
MOCKUPS
Fiecare user story care implic interfa utilizator are nevoie de un mockup
pentru a fluidiza dezvoltarea. Mockup-ul poate fi creat n diferite moduri:
desenat pe foaie, ntr-un tool de design precum Adobe Photoshop, n tool-uri
specializate de prototyping sau direct n html.
Mockup-urile sunt cel mai bine create prin colaborarea ntre designeri,
programatori i persoana care a elaborat viziunea produsului. Abordarea interdisciplinar permite identificarea mai multor detalii i clarificri la momentul potrivit.
KANBAN
Cea mai potrivit tehnic de organizare a dezvoltrii pentru un startup
este Kanban. Kanban introduce foarte puine reguli, dar destule pentru a
permite o dezvoltare fluent i mbuntire continu.
Paii pentru a adopta Kanban sunt urmtorii:
1. Identificarea etapelor din procesul de dezvoltare:
Procesul de dezvoltare este reprezentat de etapele : Analiz,
Dezvoltare, Testare, Deployment, Done.
Pot exista ns multe variaii.
Procesul trebuie s fie ct mai aproape de realitate la momentul
respectiv.
Procesul se va modifica n timp, deci nu investii prea mult timp
n identificarea exact a lui.
n cazul unei echipe noi, cel mai simplu proces este i cel mai bun
pentru a ncepe rapid.
2. Construirea unui board conform cu etapele din proces
33
3. Adugarea la boara user story-urilor i task-urilor ce trebuie fcute i

scopul lor.
4. Afiarea board-ului ntr-un loc foarte vizibil pentru ntreaga echip.
Kanban implic dou aspecte fundamentale:
Disciplin n execuie: concentrarea pe un singur scenariu la un moment dat, pe unul-dou stories (n cazul unei echipe mici) i pe finalizarea muncii n progres (work in progress) la calitatea necesar.
mbuntirea continu a procesului: atunci cnd ceva nu merge
bine (apar blocaje, story-urile se ntorc dintr-o coloan din dreapta
spre stnga, apar probleme de calitate), echipa trebuie s decid ce s
modifice pentru a preveni apariia aceluiai tip de problem.
Kanban necesit pe lng cele discutate i:
limitarea muncii n progres,
adugarea de criterii de intrare pe fiecare coloan, pentru a avea o
calitate predictibil,
monitorizarea cycle time i lead time pentru a permite mbuntirea
predictibilitii i reducerea time to market.
Aceste aspecte sunt detaliate n diverse resurse pe internet.
ACCEPTANCE TEST DRIVEN DEVELOPMENT

Aceast tehnic permite comunicarea ntre dezvoltatori i persoanele care
se concentreaz pe funcionalitile produsului.
Pornind de la criteriile de acceptan definite pentru un user story, programatorii scriu teste automate care sunt uor de citit de ctre persoane
non-tehnice. Pentru a le scrie, pot fi folosite tool-uri precum Fitnesse, Selenium sau librrii BDD precum Cucumber. Testele nu vor trece atta timp ct
funcionalitatea nu este implementat.
Test de Acceptan scris ntr-o sintax similar cu Cucumber
Feature: Find drug by name

In order to prescribe a drug fast

As a GP
34
I want to find the drug by name
Scenario: Find Aspirin by name

Given I am logged in and in the prescribe drug screen

When I search for Aspirin

Then I find all commercial names for aspirin (e.g.: Ecotrin, Acetylsalicylic
Acid, Bayer Aspirin)
Scrierea acestor teste permite clarificarea mai detaliat a cerinelor, nainte
de a fi nevoie de modificri costisitoare n cod.
CONCLUZIE
Dei dezvoltarea unui produs n cadrul unui startup este o activitate care
se desfoar la limita haosului, ea poate fi organizat ntr-un mod disciplinat
i previzibil. Avantajele acestui mod de organizare sunt evidente: eliminarea
pierderilor datorate problemelor de calitate i rework, micorarea stresului
echipei i deschiderea posibilitii de inovaie prin reducerea administraiei
necesare n condiii de haos.
Echipa Mozaic Works (www.mozaicworks.com) poate ajuta la adopia
rapid i eficient a acestor tehnici, permind echipelor s se concentreze
asupra scopului lor principal: crearea unui produs de succes.
Autor
Alexandru Bolboac - Trainer & Coach @ Mozaic Works
Mircea Vdan
Pasiunile mele sunt tehnologia, educaia i antreprenoriatul. Primele activiti antreprenoriale le-am nceput n studenie, prin mai multe proiecte
non-profit dedicate studenilor, n paralel cu frecventarea facultii (Calculatoare, UTCN).
n ultimii 3 ani, activitile mele s-au desfurat exclusiv n zona startup-urilor, mi se pare domeniul potrivit de a mbina pasiunile enumerate mai
sus. Acum lucrez n cadrul startup-ului ZenQ (www.zenq.co) i ajut la formarea comunitii de startupuri din Cluj (www.clujstartups.com).
4
VALIDAREA PROBLEMEI I A
SOLUIEI PRIN INTERVIURI
UN PRIM PAS N DEZVOLTAREA UNUI PRODUS
Acum mai bine de un an, la nceputul verii 2013, n timp ce lucram la

startup-ul UseTogether (platform de schimburi de obiecte), am analizat
mai atent metricele de pe platform, cu dorina de a hotr direcia viitoare.
n acel moment existau aproximativ 2000 de utilizatori ai platformei, aa c
a fost suficient pentru a extrage dou concluzii importante:
3% dintre utilizatorii noi postau mcar un articol i doar 1% din ei
adugau mai mult de 3;
95% din obiectele/anunurile postate nu a fost cerute de altcineva
prin platform.
Aadar, nu avea sens s continum pe aceeai direcie. De aceea, ne-am
propus s schimbm ceva. Dar ce? Ne-am gndit la schimbarea mesajului de
marketing, la a ne orienta mai mult pe cutarea de obiecte i la concentrarea
pe o ni specific, cercetnd urmtoarele segmente de pia: studeni, prini
i angajai. Considerm c fiecare dintre aceste categorii ar putea avea o oarecare nevoie de folosi o platform de acest fel, am vrut s vedem care dintre
ele are o nevoie mai mare.
Dup dou sptmni de cercetare, cea mai promitoare prea a fi nia
prinilor cu copii mici. Acetia au nevoie de multe articole pentru copii,
cheltuiesc o grmad de bani pe ele i sunt folosite pentru o perioad scurt
de timp i, n cele din urm, acele produse ajung doar s ocupe spaiul sau
garajul. De asemenea, important a fost faptul c obiceiul prinilor este deja
format, astfel nct prinii fac schimb, mprumut sau fac cadou acele arti-
38
cole n cercurile lor de prieteni.

Oricum, pentru a fi siguri de acest lucru, am nceput s facem mai multe
interviuri de validare a problemei cu diveri prini: mai tineri i mai n
vrst, cu un venit mai mic sau mai mare, cu copii mici sau cu copii de 5-7
ani. Voiam s fim ct mai siguri i s nelegem prinii, nevoile i comportamentul lor precum i modul n care o platform ca a noastr i poate
ajuta. Din fericire am avut unele cunotine dobndite n unele workshopuri privind validarea problemei i astfel aveam noiunile de baz cu care s
pornim. Pe lng cteva chestionare i focus grupuri, am avut i cteva zeci de
interviuri fa n fa, acestea fiind cele mai importante c s ne dm seama
de nuanele problemei.
Mai jos voi descrie structura general aplicat la interviuri. Mi s-a prut
un model bun i destul de obiectiv. Practic, exist cteva ntrebri de baz, iar
alte ntrebri satelit pot fi adugate n jurul acestora. Materialele studiate pe
care s-a bazat structura de mai jos le gsii la sfritul capitolului.
n primul rnd, pentru a obine o validare sincer, persoanele intervievate
nu ar trebui s tie nimic despre ceea ce vrei s construii (sau cu ct mai
puin cu att mai bine). Ideea este de a pune ntrebri generale i apoi de a
intra mai adnc n descrierea problemei, prin ntrebri deschise.
1. Care sunt problemele pe care le ntmpini legate de ...?
De exemplu, la ntrebarea Spune-mi despre problemele pe care le-ai
ntlnit, legate de creterea copiilor, probabil ei vor meniona problemele
de sntate, cutarea informaiilor necesare, banii cheltuii pe diverse lucruri
pentru copil. n acest pas, ar trebui s existe o referire la problema pe care
dorii s o abordai. n exemplul de mai sus este vorba de cheltuieli pe diverse
lucruri. Apoi pot urma alte ntrebri n aa fel nct s simim, ca intervievatori c am neles bine perspectiva intervievatului asupra problemei/nevoii
existente.
2. Care sunt variantele pe care le utilizezi pentru a rezolva aceast
problem?
Deoarece este o problem, oamenii ncearc s o rezolve cumva, offline
(de exemplu: i sun prietenii, cer ajutor profesionist, merg la evenimente
de vnzare-cumprare obiecte sau viziteaz magazine) sau online (cutare pe
Google, postarea pe grupuri de Facebook, verificarea site-urilor specializate OLX.ro, Tocmai.ro, etc.). Prin gsirea variantelor folosite i dai seama care
VALIDAREA PROBLEMEI I A SOLUIEI PRIN INTERVIURI
39
va fi concurena ta direct sau indirect, prin prisma celui intervievat.

3. Ce probleme vezi la aceste variante?
Poate c aceste variante sunt prea greu de folosit sau este nevoie de
mult timp/ muli bani sau au user-experience neplcut. Aceste aspecte
sunt i motive pentru a utiliza produsul dvs. comparativ cu acele alternative sau sunt sugestii despre ce ar trebui s evii sau s aplici mai bine.
Ideea este ca produsul tu s rezolve o problem i s aduc valoare n
plus clienilor poteniali, comparativ cu ceea ce exist deja pentru ei.
Fr a lua n considerare acest aspect, nu prea mai are sens acest demers.
4. Care este soluia perfect pentru tine?
n acest moment, intervievaii s-au gndit deja profund la situaia lor i
la cteva idei despre cum lucrurile pot fi mbuntite, astfel nct poi s-i
ndemni s-i imagineze soluia potrivit/ideal pentru ei. S-ar putea obine
unele sfaturi surprinztoare, idei creative sau ntr-adevr diferite fa de ceea
ce aveai n minte. n cazul n care primeti rspunsuri care sunt apropiate de
soluia gndit de tine anterior, soluia ta este validat cel puin prin aceast
metod.
Aici poate s se ncheie prima parte a interviului. n acest moment poi
meniona ceea ce ai de gnd s faci, poi descrie detaliile, feature-uri i poi
cere feedback direct, arat chiar i wireframe-uri. Aceasta este de fapt a doua
parte a interviului, o discuie liber cu scopul de a primi ct mai mult feedback
legat de idee.
n final, e important s i ntrebi cu cine ar mai trebui s vorbeti sau pe
cine i pot ei recomanda? Toi aceti intervievai pot constitui utilizatorii
iniiali, pentru c ai stabilit deja cu ei o legtur care i poate oferi feedback
n continuare.
Repet acest tip de interviu de cel puin 20 de ori pe segmentul semnificativ. Adaug chestionare online i focus grupuri, n scopul de a obine mai
multe idei sau pentru a confirma ceea ce tii deja i abia apoi ncepe construirea propriu-zis a produsului.
CTEVA SFATURI
Nu construi nimic fr validare cu poteniali clieni.
Este important s afli ce funcioneaz i ce nu, nainte de a construi
un MVP.
40
Stabilete categorii ale posibililor clieni i clasific interviurile pe diverse pe segmente

Descoper n fiecare segment pe cei care au potenial de early adopters
adic pe cei pentru care produsul tu e must-have, nu nice-to-have.
Realizeaz interviuri pn cnd vei vedea c rspunsurile sunt similare sau se repet des, pentru a extrage concluzii relevante.
Reitereaz interviurile sau adapteaz-le n funcie de rezultatele din
interviurile anterioare.
Utilizeaz cuvinte ale clienilor n frazarea mesajului de marketing.
Atunci cnd vorbeti despre produs, subliniaz mai nti beneficiile
pentru client.
Pe ct posibil, f o astfel de validare pentru fiecare feature nou.
Provocarea n acest moment nu este de a obine noi utilizatori, ci de
a obine utilizatorii pentru care produsul rezolv ntr-adevr o problem.
Evideniaz fapte i ntmplri reale, care s reflecte comportamentul
autentic. De multe ori utilizatorii au o prere, dar au comportament
diferit fa de ceea ce afirm.
n ceea ce privete acest subiect, materialele urmtoare s-au dovedit a fi
foarte utile:
1. Founder Centric (Rob Fitzpatrick, Sal Virami)
cartea The Mom Test1
prezentarea Early Stage Customer Development2
prezentarea Practical Customer Development - Lean Startup3
3. Andreas Klinger4
4. Steve Blank:
http://steveblank.com/category/customerdevelopment/
http://www.slideshare.net/venturehacks/customer-development-methodology-presentation
http://www.youtube.com/watch?v=6t0tCXPpyM .
5. Cindy Alvarezs blog5
Fiecare dintre autorii menionai mai sus vine cu un punct de vedere uor
1 http://momtestbook.com
2 http://vimeo.com/40192415
3 http://www.slideshare.net/foundercentric/practical-customer-development-lean-startup-groningen
4 http://www.slideshare.net/andreasklinger/actionable-customer-development
5 http://www.cindyalvarez.com/learning/faq-customer-development-for-product-managers
VALIDAREA PROBLEMEI I A SOLUIEI PRIN INTERVIURI
41
diferit, dar complementnd perspectiva validrii problemei i a soluiei. Toi

ajung la aceeai concluzie: construiete ceva ce oamenii i doresc, verific
ipotezele prin fapte i experiene reale, vorbete cu posibili clieni ct mai
mult posibil .
Nu cred c aceast metod a interviurilor este infailibil, mai ales c n
unele cazuri, cnd e vorba despre anumite nevoie necontientizate nc n
mintea posibililor utilizatori, este chiar greu de aplicat. n asamblu mi s-a
prut un proces foarte folositor care n acel moment ne-a ajutat s nelegem
mult mai bine problema prinilor i abordarea de urmat.
Efortul investit n dezvoltarea unui produs este foarte mare i riscul este
pe msur. Dar prin metodele elaborate i folosite de startup-uri, un produs
poate ajunge de la nceput mai aproape de nevoile clientului. Dac ai nevoie
de ajutor n acest proces, scrie-mi un e-mail la mircea.vadan@gmail.com
Autor
Mircea Vdan - clujstartups.com
Sebastian Big
Sebastian Big, pe care l gsii pe sebastianbig.ro, este unul dintre cei mai
buni clarvztori sintactici pe plan naional, o meserie de viitor n timpuri de
criz nu att economic, ct conceptual.
Profeii semantice de orice natur: social, psihologic, tehnologic etc.,
s-au ncercat de multe ori n trecut, dar rezultatele au fost dezamgitoare iar
direciile de urmat neclare, n ciuda eforturilor asidue ale respectivelor scene
de a le urma.
Interaction Designer, dar de formaie filozofic i cu traduceri din Virilio, Baudrillard, Derrida & Stiegler i un doctorat n Comunicare terminat
prematur, Sebastian Big i valorific talentul pe piaa romneasca de IT,
ncercnd s pun n valoare metodele sale de clarviziune ntr-un sistem deocamdat cantonat n factualitatea imediat.
5
CUM PUTEM GNDI INTERACTIV
USER EXPERIENCE-UL?
Dup cum precizeaz majoritatea ncercrilor de definire a acestui domeniu multidisciplinar, UX-designul ncorporeaz, pe de o parte, aspecte din
discipline tehnice: informatic, arhitectur, design grafic, design industrial
i, pe de alt parte, se strduiete s integreze aspecte din tiinele umane:
tiine cognitive, psihologie, antropologie, sociologie. De ce tiine umane?
Pi, e foarte simplu, pentru c au ca domeniu de activitate tocmai omul (userul) i existena (experiena) lui. tiinele umane sunt ns o invenie destul de
recent (cel mult 150 de ani) fa de disciplina cu acelai obiect de activitate,
din care s-au dezvoltat i ele: filosofia. n ce privete omul i ce i se ntmpl
acestuia, filosofia are o expertiz de peste 2000 de ani.
Istoria filosofiei se mparte ndeobte n trei perioade: antichitatea, modernitatea i contemporaneitatea, fiecare cu tematica ei specific. Obiectul
principal al filosofiei antice a fost ceea ce este, fiina, modernitatea s-a
ocupat de cunoatere, iar tematica vremurilor noastre e comunicarea, tehnologia informaiei fiind un caz particular al acestei ultime etape. Fiecare
dintre aceste etape e marcat conceptual de o relaie opozitiv. Vom vedea pe
parcursul acestei prezentri felul n care a rezolvat filosofia aceste conflicte i
vom ncerca s ne dm seama n ce msur rezolvrile ei ne pot ajuta n mai
buna nelegere a conceptului de user experience.
44
CELE TREI ETAPE ALE FILOSOFIEI I

CONFLICTELE LOR
ANTICHITATEA GREAC - ESEN VS. EXISTEN
Filosofia se nate n Grecia antic, odat cu trecerea de la ritualurile credinelor primitive la discursul raional. Absolutul credinelor primitive este
abstractizat n Principii. La fel ca i n cazul sacrului, omul trebuie s le
cunoasc pentru a putea nelege lumea. Marea problem a acestei etape a
aprut odat cu aprofundarea relaiei dintre principiu i manifestrile sale.
Ce este aparen i ce este realitate, ce e iluzoriu i ce exist cu adevrat n
aceast lume, schimbarea sau statornicia?
Prima soluie la aceast problem o d Heraclit din Efes. Dup el, universul se transform n fiece clip. Totul este pus n micare de un dinamism
infinit, iar principiul e puterea schimbrii, manifestat prin micare. Totul
curge (Panta rhei), totul este (n) micare, tot ce exist este prins ntr-o continu mobilitate.
O alt soluie vine de la Parmenide din Elea, care neag schimbarea /
transformarea. Pentru el, din punctul de vedere al principiului, al Fiinei,
schimbarea i micarea sunt iluzorii, iar devenirea este doar o aparen. Numai simurile sunt vinovate de aceast iluzie pentru c ne fac s credem n
curgerea necontenit a fenomenelor. Raiunea mprtie iluzia, artndu-ne
ce este real, Fiina unic, imobil, etern, ascuns sub valul aparenelor multiple.
PERIOADA MODERN RAIONALISM VS. EMPIRISM
Perioada modern e marcat de descoperirile geografice, de trecerea de
la perspectiva geocentric la cea heliocentric, stnd n general sub semnul
schimbrii modurilor de cunoatere. Instalarea i ascensiunea cunoaterii n
cultura occidental este concomitent cu instalarea tiinelor moderne, a cunoaterii tiinifice moderne. Problema modernitii e urmtoarea: dac realitatea este relativ la cunoatere este vital s tim care este sursa cunoaterii
adevrate. E real ceea ce cunoatem prin simuri sau ceea ce cunoatem prin
raiune? i aici, ca i pentru filosofia antichitii, se desprind dou soluii
posibile.
Empirismul postuleaz teoria conform creia experiena senzorial e cea
45
care face posibil cunoaterea noastr. Simurile ne dau toate datele brute
despre lume, material fr de care nu ar exista cunoaterea. Percepia este
punctul de plecare al unui proces la finalul cruia ajungem s avem certitudini. Doar percepia este cea care poate aduce cunoatere.
Raionalismul pretinde c nu simurile, ci raiunea e punctul de plecare al
oricrei cunoateri. Raionalitii pretind c fr categorii i principii a priori
furnizate de raiune nu am putea organiza i interpreta experiena noastr
senzorial. Am avea de-a face cu un imens, nedifereniat caleidoscop de senzaii fr semnificaie.
Doar principiile i conceptele generate i certificate de raiune i doar
ceea ce e deductibil logic din ele poate oferi cunoatere.
CONTEMPORANEITATE STRUCTUR VS NARAIUNE
Nu voi descrie aici felul n care se desfoar lucrurile n contemporaneitate. Suntem cu toii prezeni. Voi spune doar c, n ce privete filosofia, avem
n continuare de-a face cu o relaie conflictual, reprezentat de aceast dat
de coala structuralist i de cea hermeneutic. Cele dou au evident moduri
diferite de a vedea comunicarea.
Structuralismul este o orientare teoretic i metodologic interdisciplinar care studiaz structura, funciile i sistemele de relaii ce caracterizeaz
realitatea, punnd n prim-plan totalitatea n raport cu individul i sincronicitatea faptelor n raport cu istoria. Semnificaia e un rezultat al relaiilor
interne ale sistemului ca ntreg. Comunicarea ar fi n acest caz cu att mai
precis cu ct indivizii implicai n actul ei stpnesc structura respectivului
sistem.
Pentru hermenenutic, ce pune n fa individul, realitatea e compus
din mpletirea unor naraiuni individuale. nelegerea se realizeaz prin interpretarea perpetu a propriilor naraiuni i compararea lor cu naraiunile
celorlali i cu poveti generice (biblia, talmudul etc.). Istoria ca desfurare
temporal are preeminen n acest caz, diacronia are ctig de cauz n faa
sincroniei. n cazul hermeneuticii comunicarea e un proces nesfrit n care
semnificaia e ntotdeauna nou, momentan i emoional.
46
REZOLVRILE CELOR TREI ETAPE

ANTICHITATE
Problema cu perspectiva lui Heraclit e c ajungem s ne situm ntr-un
relativism total n care nu exist nimic statornic, cunoatere, moral, legalitate, sentimente etc. . Dac i dm dreptate lui Parmenide, salvm toate aceste
forme i coninuturi ale vieii noastre, dar ajungem s ne situm n contradicie cu lumea pe care ne-o prezint simurile noastre.
Platon e primul care leag termenii acestei dihotomii, spunnd c lumea
pe care o ofer senzaiile noastre, lumea fenomenelor naturale i a corporalitii, schimbtoare, trectoare i contradictorie, e o copie a lumii ideilor, a
realitii absolute, eterne i adevrate, introducnd astfel n istoria filosofiei
diferena dintre imanent i transcendent. Cele dou sunt legate, ns transcendentul poate exista i fr copia lui palid, imanentul. Mai cu picioarele
pe pmnt, Aristotel ia doctrina platonician, abstractizeaz lumea ideilor,
reducnd-o la cauze (categorii) cu neles de principii, care stau la baza oricrei existene individuale. Lucrurile i fiinele exist n poten, dar nu se pot
actualiza fr a fi nscrise n categorii. Pentru a nelege mai bine relaia posibilitate-actualizare, s ne lum la dou exemple: copilul este posibilitatea, iar
actualizarea lui este fiina uman matur; un proiect este n posibilitate, iar
actualizarea lui este un obiect, o cldire, o aplicaie. Nu exist categorie fr
actualizare, aa cum nu exist nici actualizare fr categorie.
MODERNITATEA
Problema raionalismului e c aplicnd doar raiunea la experien, e foarte probabil c vom ajunge la iluzii teoretice. Cu empirismul problema e c
experiena ar fi total subiectiv i haotic fr s fie filtrat de raiune.
Kant e cel care mpac cele dou curente de gndire - categoriile sunt cele
care sintetizeaz datele diversitii senzoriale n obiecte inteligibile. Simurile procur minii intuiiile, iar capacitatea de judecat produce judeci asupra acestor intuiii, grupndu-le n categorii. Categoriile ridic intuiiile din
contiinta momentan a subiectului, plasndu-le ntr-o contiin general,
producnd coninuturi de cunoatere universale. Astfel constituit, subiectul
este capabil s organizeze influenele haotice pe care le exercit asupra sa
mediul su i s constituie prin aceast organizare obiectul cunoaterii sale.
47
CONTEMPORAN
Problema cu structuralismul e c semanticul vine ntr-un plan secundar
n raport cu sintacticul. Semnificaia e secundar gramaticii. Comunicarea
e pur funcional i golit de emoie. Riscul abordrii hermeneutice, pe de
alt parte, e acela al unei reele de comunicare fr cap i coad, de tip Turn
Babel, imposibil de gestionat, n care comunicarea real ar fi random.
Rezolvarea conflictului dintre cele dou perspective e ceva ce se ntmpl
as we speak. Structura este cea care ordoneaz diversitatea naraiunilor personale. De la comuniti complet izolate n spaiu i timp am ajuns n satul
global, cu limbaj i pattern-uri de comportament globale. Gndim (structurat) global i acionm (producem naraiuni) local.
CONCLUZII
Dup cum am vzut, fiecare dintre cele trei perioade din istoria filosofiei e
marcat de dou feluri de a vedea lucrurile, la prima vedere diametral opuse,
fr putin de mpcare. Fiecare perspectiv are ns lipsurile ei, niciuna
dintre ele nu reuete s ofere o viziune global, funcional asupra epocii
respective. De fiecare dat, lucrurile ncep s capete sens n momentul n
care apare cineva care s le pun n interaciune. Dei nu e o munc uoar conceptual, simplul fapt de a vedea posibilitatea interaciunii dintre cele
dou perspective deschide un front de lucru care nu poate dect s duc la
rezolvarea situaiei opozitive.
Afirmam mai spus c epoca n care trim e marcat de tehnologie. Dac
pentru antici era vorba despre a tri, pentru moderni despre a cunoate, iar
pentru contemporanul secolului trecut despre a comunica, n prezent, legtura sau felul n care oamenii interacioneaz cu tehnologia poart numele
de user experience. S vedem, n ncheiere, n ce msur ne putem folosi de
know-how-ul filosofiei pentru a defini cuplul opozitiv care marcheaz user
experience-ul i pentru a gestiona aceast relaie aparent dihotomic.
Dac ar fi s analizm user experience-ul printr-un ochi-rezumat al celor
trei etape, avem pe de o parte un nucleu dur, care spune c numai principiile,
categoriile i structura conteaz, c tehnologia este ceva ideal, care nu are nevoie de nicio poveste, de nicio zorzoan care s distrag atenia de la adevrul
ei transcendent, la care user-ul nu poate ajunge dect printr-un travaliu de
aceeai intensitate cu cel depus de nucleul dur de mai sus.
La captul opus se afl cei nzestrai cu harul soft-skill-urilor, din perspectiva crora principiile i categoriile sunt ceva de ocolit, structura e ceva
48
colateral, iar ceea ce conteaz cu adevrat e doar impresia artistic care s

gdile simurile user-ului. Interfaa noastr cu tehnologia e un talme-balme
nesustenabil, generat de un user research menit s satisfac apsrile artistice
i de comunicare ale departamentului de marketing.
Cum am vzut din povestea filosofiei, niciuna dintre variante nu rezolv
singur problema user-experience-ului. Un user-experience strict bazat pe principii, categorii, structuri e gol, rece i greu de folosit, tocmai pentru c nu ine
cont de user-i. Un user-experience bazat doar pe simuri, percepii i naraiuni
e haotic i n cele din urm la fel de greu de folosit, neavnd o structur.
Ce se ntmpl n momentul n care punem s interacioneze cele dou
perspective? Structura adun i abstractizeaz naraiunile, transformndu-le
n pattern-uri. Naraiunile sunt cele care furnizeaz crmizile din care e
construit structura, care nu e altceva dect un sistem de componente i
comportamente, adic un framework. Parafraznd un celebru om politic romn: Existena unui framework nu se discut, se afirm.
Nu e o ntmplare deci faptul UX-ul funcioneaz, aa cum spuneam n
introducere, la intersecia dintre disciplinele tehnice, reci, formale, logice i
tiinele umane, care tiu s neleag i s pun n scen latura emoional a
user-ului nostru cel de toate zilele.
Autor
Sebastian Big - interaction designer @ Betfair
49
Diana Ciorba
Diana Ciorba coordoneaz cu dedicare strategia de marketing a companiei Codespring, din 2009. Furniznd constant informaii despre pia i
despre expertiza echipei, ea a devenit un ambasador activ al comunitii IT
din Cluj.
Srbtorind 11 ani de provocri n marketing i dezvoltarea afacerilor,
de-a lungul ultimilor 7 ani a avut i rolul de consultant independent pentru
investitori din ar i strintate. Alturi de experi i manageri executivi,
pentru ea, munca multi i interdisciplinar este o plcere.
nelegnd antreprenoriatul ca un stil de via diferit, creterea afacerilor
este ntotdeauna o preocupare prioritar. Diana consider activitatea de marketing i dezvoltare n ITC un teren propice pentru o minte jucu.
Studiile din Frana au influenat parcursul academic al Dianei, ea deinnd
n prezent un master n Management. Cu un palmares ce include premii n
domeniul artelor dramatice, scrierii creative i tiinifice, Diana este un autentic specialist hibrid.
6
PRIVIND CU OCHII
UTILIZATORULUI FINAL
Construirea unui produs software viabil este un proces complex, de durat,

care implic specialiti din domenii diverse. Adeseori la ntrebarea CUM ?
rspunsul cel mai sincer pe care l pot da este: Depinde! Astfel, semnalizez n
mintea interlocutorului multitudinea de factori ce afecteaz modalitatea n
care se poate ajunge la rezultatul dorit. Implicit, pim pe terenul ntrebrilor
exploratorii ntrebri eseniale n demersul decizional pe care l parcurgem
n vederea construirii unui produs software i nu numai (!). Cu ct vom avea
rspunsuri mai clare, mai cuprinztoare, mai documentate, cu att decizia va
fi mai bine fundamentat i mai rafinat.
Din experiena direct, am reinut c att echipele tehnice, ct i cele
comerciale care particip la construirea produselor software i la punerea la
punct a proceselor corelate, cad de acord asupra unui aspect fundamental:
construim pentru oameni i aceasta schimb tot.
#1 CONSTRUIM PENTRU OAMENI

Pentru a ne da seama de complexitatea domeniului trebuie doar s
observm cele dou elemente implicate. De o parte regsim utilizatorul
uman; de cealalt parte se afl computerul. Comunicarea dintre cele dou
elemente se face cu un scop prestabilit, n funcie de domeniu. Tipul
de input acceptat de computer i tipul de output pe care programul l
furnizeaz va determina interfaa cu utilizatorul.
Oamenii au nivele diferite de pregtire i cunotine n utilizarea com-
52
puterelor i dispozitivelor ce ncorporeaz tehnologie nalt. Avem de-a face

cu o gam larg de utilizatori de la utilizatori elementari pn la utilizatori
extremi.
Echipa de dezvoltare a unui nou produs sau a unei noi versiuni a unui
produs deja existent va trebui s in cont de aceast diversitate i s hotrasc cea mai eficient abordare. Totodat, va trebui s inem cont de faptul c
utilizatorul final i cumprtorul sunt dou specii diferite. Produsul software
construit trebuie s fie bine primit de utilizatorul final.
#2 OAMENII VOR S SE SIMT BINE

Din natere, omul caut experienele care l fac s se simt bine. Fie c
avem de-a face cu un program destinat activitilor profesionale, fie celor
recreative, utilizatorul final va trebui s aib o experien plcut n interaciunea cu produsul software i cu dispozitivul pe care este instalat.
Experiena plcut a utilizatorului unui produs software este greu de
definit datorit factorilor cu un grad mare de complexitate care o afecteaz.
n funcie de domeniul de aplicabilitate i tipul de utilizator, stabilirea unui
set de criterii prin care se va evalua nivelul de satisfacie n utilizare va spori
sanele dezirabilitii produsului n pia.
#3 OAMENII CAUT S FIE LIBERI

Printre ateptrile fa de tehnologia de vrf se numr i obinerea unui
grad sporit de libertate, precum: libertatea de a se mica, libertatea de a explora (mediul conjurtor, datele, fenomenele).
Acest fapt a determinat i permanenta evoluie a tehnologiilor de interaciune ntre om i computer de la cele non-perceptuale (tastatur, joystick,
mnu electronic, stilet, dispozitive i suprafee tangibile) spre cele perceptuale (de vedere, auz i percepie la distan). n plus, exist deja tehnologii
ce permit input further out: cele bazate pe gesturi, palpaie, biometrie sau
impulsul nervos.
n funcie de domeniul de aplicabilitate al produsului software, echipa de
proiectare va trebui s analizeze specificul activitii utilizatorilor finali pentru a putea oferi un produs performant, de ncredere i care s elibereze corpul
de manevrarea unor obiecte i de prezena ntr-o anumit locaie.
53
Avnd aceste principii fundamentale n minte, demersul construirii unui

produs software poate avea dou direcii: a) cineva are o idee ce va trebui
testat i verificat sau b) se pornete analiza nevoilor nesatisfcute de ctre
produsele existente n scopul soluionrii acestora. n ambele cazuri, buna
practic presupune analiza cerinelor de pia i conturarea cerinelor pe care
produsul va trebui s le ndeplineasc.
#4 MRD (MARKET REQUIREMENT DOCUMENT)

Documentul care va articula noul produs i planul de lansare al acestuia
este MRD (Market Requirement Document), uneori numit i PRD (Product Requirement Document) sau BRD (Business Requirement Document).
Coninutul su vizeaz identificarea problemei de rezolvat sau nevoii de
acoperit, analiza ct mai detaliat i cuprinztoare a acesteia, propunerea de
soluii, dezvoltarea i testarea.
Acesta va avea n centrul ateniei utilizatorul i modul n care acesta va
interaciona cu produsul nou lansat sau cu ultima sa versiune. Adeseori s-ar
putea ca utilizatorul s gseasc noi variante de utilizare, la care proiectanii
nici nu s-au gndit. Tocmai de aceea activitile de prototipare i testare cu
poteniali utilizatori finali trebuie prevzute n planul de dezvoltare.
Prin acest document se vor deschide i opiunile decizionale legate de
afacerea proprie:
Putem identifica un concept pe care potenialii clieni s doreasc s
l probeze?
Putem identifica o strategie de marketing eficient pentru a introduce
i creste produsul pe pia?
Va corespunde produsul condiiilor noastre de profitabilitate i rentabilitate?
Dac rspunsurile la ntrebrile de mai sus vor fi pozitive, se poate trece la
predarea cerinelor i ideilor deja generate ctre echipa de dezvoltare care va
parcurge procesul de dezvoltare al unui produs software.
#5 REGLAJUL FIN LA FIECARE PAS

Att echipa responsabil de aspectele comerciale ct i cea de aspectele
54
tehnice vor fi cu att mai performante cu ct vor fi mai receptive. Pentru a

crete receptivitatea de ansamblu, coordonatorul activitii de marketing i
cel al dezvoltrii produsului vor trebui s pun la punct un sistem prin care
s existe n permanen puncte de contact pentru preluarea informaiei de la
piaa int, de la clientul ordonator, de la utilizatorii finali.
Receptivitatea are ca scop final creterea anselor de a oferi din start o
valoare autentic n fiecare etap de dezvoltare a produsului software. Valoarea perceput de utilizatorii finali i cumprtori va determina strategia de
pre a produsului i capacitatea de a ctiga piaa.
Un exemplu n sensul creterii valorii percepute per ansamblu este programul pus la punct la Codespring: reglajul fin la fiecare pas.
Figura 1: Procesul de dezvoltare software bazat pe principiul reglajului

fin la Codespring / sursa: Catalogul Codespring, ed. 2014
Fondatorul companiei, ing. Levente Szelyes alturi de echipa sa, au dezvoltat parteneriate strategice pentru dezvoltarea de produse software complexe cu civa din liderii mondiali n industriile lor. n paralel, compania
are i produse software proprii. Rezultatele pozitive au fost posibile datorit
acurateii cu care se deruleaz procesele de analiz, planificare i dezvoltare.
Acurateea perceptibil n produsele software dezvoltate de Codespring
are la baza acest mecanism sofisticat de reglaj fin al tuturor variabilelor i
resurselor implicate n proces.
55
Mai mult, reglajul fin a devenit un principiu guvernator al organizaiei,

n relaie cu piaa, clienii existeni i cei poteniali. Mecanismul st la baza
ctigrii ncrederii clienilor i meninerii flexibilitaii organizaiei pe
msur ce se dezvolt.
Figura 2: Reglajul fin ca principiu guvernator al organizaiei / sursa: Catalogul Codespring, ed. 2014
#6 IMPLICAREA UTILIZATORILOR N
PROTOTIPARE I TESTARE
Timpul de proiectare i lansare pe pia a unui produs software de calitate
poate varia n funcie de resursele disponibile: tehnice, financiare i umane.
Practica din domeniu a consacrat prototiparea i testarea ca dou etape ce
pot avea o influen major asupra calitii rezultatului final. Din perspectiva utilizatorului, acestea sunt momente critice n care se poate manifesta i
poate participa la conturarea produsului pe care probabil l va folosi n viitor.
Observarea utilizatorilor n interaciunea cu prototipurile vor oferi informaii valoroase n legtur cu: reacia fa de probabila interfa, modul
n care ar utiliza funcionalitile produsului, experiena pe care ar putea-o
tri utilizatorul. Ulterior, echipa de proiectare va putea propune schimbri,
56
mbuntiri i completri. Avantajul colaborrii n aceast etap este apropierea de un rezultat ct mai util i plcut utilizatorului int.
Testarea cu utilizatorii int este o evaluare concluziv a produsului
nainte de distribuirea pe piaa int. n cazul unei evaluri pozitive, se poate
considera lansarea pe pia i creterea produsului. Este o etap prin care se
pot colecta informaii despre comportamentul utilizatorilor i despre viteza
cu care adopt noul produs sau noua versiune.
#7 PRIETENIA CU NOILE
GENERAII DE UTILIZATORI
Dac pn acum vorbeam de noua generaie de tehnologie, e timpul s
atragem atenia i asupra noilor generaii de utilizatori. Viteza cu care absorbim fiecare nou dezvoltare tehnologic i cea cu care copiii i adolescenii
reuesc s le exploateze, indic o cretere vertiginoas a abilitii acestora de a
interaciona cu tehnologia. Comportamentul acestor noi generaii va diferi,
fiind deja influenat de hiperconectivitate, mobilitate i accesul la realiti
diferite.
Apropierea organizaiilor ITC de noile generaii este imperativ. Consider c persoanele avnd rol de strateg n dezvoltarea afacerilor, respectiv
n dezvoltarea de produse software - n special, pot gsi o surs de inspiraie
pentru viitorul apropiat analiznd comportamentele proeminente din rndul
noilor generaii. Adeseori, sinceritatea brut a copiilor i adolescenilor poate
ajuta dezvoltatorii unui nou produs n identificarea punctelor slabe sau unor
noi oportuniti. Bineneles i pentru obinerea acestor informaii o sistematizare a mijloacelor de colectare este necesar.
#8 INOVAREA CA STARE MENTAL

Avnd n minte utilizatorul final, construirea unui produs software trebuie
s aib n vedere o mbuntire semnificativ sau chiar o premier a modului
de rezolvare a unei probleme date. Prin caracteristicile intrinseci ale domeniului ITC, dezvoltarea produselor software este un proces creativ n relaie
imediat cu inovarea.
Inovarea de produs, de proces, de organizare, de metod sau de marketing
are loc atunci cnd condiiile sunt prielnice. Terenul pentru inovare la scar
57
mare se poate pregti din timp prin adresarea unor ntrebari simple de
genul: Cum am putea opera un pacient la distan? sau Cum am putea
nva tipul de lovituri pe un teren de golf, fr instructor? sau Cum am
putea monitoriza sntatea ecosistemului marin?... ntrebrile se vor adresa
att specialitilor ct i potenialilor utilizatori finali. Adresnd ntrebri i
ateptnd rspunsuri antrenm echipa s vin cu idei, soluii i inducem
utilizatorilor finali ideea c o soluie ar fi posibil pentru nevoia lor.
Aliniind organizaia i beneficiarii direci la ideea de propunerea a unor
soluii, crem podul spre inovare.
#9 UTILIZATOR FINAL NU
NSEAMN CUMPRTOR
Un produs software poate fi construit pentru uz direct, personal (pe computerul personal, pe telefonul mobil personal, etc.) sau pentru uz direct, profesional (pe computerul sau staia de lucru a companiei, pe telefonul de serviciu, n maina de serviciu, etc.). Dei n ambele cazuri, echipa de proiectare
va avea n vedere utilizatorul final, va trebui fcut distincia ntre situaia
n care acesta are i puterea de a decide achiziia i situaia n care echipa de
achiziii a companiei va decide pentru el.
Lanul decizional va afecta resursele alocate dezvoltrii produsului software, versiunea final i modalitatea de punere pe pia.
#10 COMUNICAREA UMAN ESTE ESENIAL

Prezena sau lipsa unui salut cordial, verbal sau n scris, poate decide
startul oricrei colaborri. Pentru a asigura un nivel ridicat de veridicitate
a datelor colectate despre utilizatori i nevoile lor, un volum i o varietate
adecvat de date pentru conceperea sau dezvoltarea produsului software, comunicarea trebuie s fie bine pus la punct: ce ntrebri se vor adresa, cum
vor fi transmise, cum se vor primi rspunsurile, n ce context (locaie, numr
de persoane prezente, timpul, durata, etc.).
Ulterior, comunicarea rezultatelor ctre echipa de proiect i modul n care
acestea vor fi nelese vor contura forma i structura primar a produsului.
Pe parcursul dezvoltrii comunicarea interpersonal i de grup (de echip) va
influena major viteza de rezolvare a sarcinilor, calitatea soluiilor i fiabili-
58
tatea lor. n final, comunicarea produsului i a beneficiilor sale ctre publicul

int va determina succesul comercial al produsului dezvoltat.
Privit din perspective diverse, construirea unui produs software poate fi
descris diferit. Definirea corect a utilitii acestuia ne duce spre utilizatorul
final, adic oamenii care l vor folosi n activitile lor. Astfel utilizatorul final
este punctul de convergen al tuturor specialitilor implicai n acest proces.
Privind prin ochii utilizatorului final tim ctre ce trebuie s ne ndreptm i
tot de aici pornim pentru a reevalua i a demara urmtoarea etap.
BIBLIOGRAFIE
1. Catalog Codespring, ediia 2014.

2. Diana Ciorba - Interviu: CEO-ul Codespring despre reglajul fin, iunie 2013.
3. Diana Ciorba HCI (Human-Computer Interaction): On the Verge of Change
- Publicaia Codespring Company Papers, ediia nr. 9, septembrie 2012.
4. John W. Ryan - Buyer Steps,2011, ISBN-1460988612.
5. P. Kotler, K.L. Keller, M. Brady, M. Goodman, T. Hansen - Marketing Management; Education Limited 2009, ISBN 978-0-273-71856-7.
6. E. N. Berkowitz, R. A. Kerin, S. W. Hartley, W. Rudelius - Marketing; Richard
D. Irwin Inc. 1994, Printed in the U.S. A, 1234567890 VH 09876543.
Autor
Diana Ciorba - Marketing Manager @ Codespring
59
Zornitsa Tomova
Imediat dup absolvirea Masteratului de Inginerie i Management al

Afacerilor din cadrul Universitii Warwick (UK), Zori a co-fondat compania britanico-bulgar 42 IDEAS i, timp de doi ani, a fost consultant pe inovaie n servicii i producie, att pentru companii, ct i pentru startup-uri
i ONGuri. Membr a organizaiei non-profit Start It Smart, a organizat
evenimente i programe cu scopul de a sprijini tinerii n nceperea afacerilor
proprii.
n 2013, ca parte din echipa UseTogether, Zori a format comunitatea
de sharing economy din Bulgaria. La nceputul anului 2014 a lsat totul n
urm, pentru a ncepe ZenQ (Ze way to say thank you and appreciate your
friends. On your mobile. n zeconds.)
12
MANAGEMENTUL PRODUSELOR
PENTRU STARTUP-URI:
EXPERIENA ZENQ
Totul a nceput ntr-o cafenea Starbucks din Sofia (Bulgaria), la sfritul

lui 2013, cnd hazardul mi-a oferit ocazia ntlnirii cu o persoan care mi-a
influenat ulterior evoluia mea profesional. Preocuprile profesionale comune au reprezentat obiectul principal al conversaiei noastre.
I-am explicat c mi conduc propria companie de consultan de mai bine
de doi ani, ajutnd companiile s dezvolte produse inovatoare n IT, producie, servicii i alte sectoare. De asemenea, conduceam proiecte care ofereau
oamenilor sprijin n nceperea afacerilor, ca membru al Start It Smart NGO.
De asemenea, ajutam startup-ul UseTogether din Cluj s i construiasc
comunitatea n Bulgaria. i una i alta. Cum spunem noi n Bulgaria, fie ca
ultimul s nchid ua.
La rndul meu, am aflat c venea din Israel i construise cteva afaceri
care fcuser sute de milioane. Acum cuta oameni care s l ajute s o dezvolte pe urmtoarea o aplicaie pe mobil foarte simpl care s i permit
s salvezi poze pe telefoanele prietenilor sau ale familiei tale. Nu aveam nicio
idee despre mobile la acea vreme (nu aveam smartphone, pentru ca s evit
dependena de reele sociale, jocuri i n general dependena de mobil). De la
aceast simpl conversaie, am ajuns la o colaborare, n urma creia am reuit
s fac foarte multe progrese: am nvat cum s nv, cum s fiu imperfect i
s fiu OK cu asta, cum s visez i s mi urmez visele. Tocmai aceast ultim
lecie a fost cea care n final m-a fcut s ncetez colaborarea i, cu un mic
impuls din partea unui prieten din Cluj, s ncep ceva nou care imediat s-a
transformat din vis n realitate.
62
NCEPE ZENQ
Eu i cu Mircea am nceput s punem la cale ZenQ o aplicaie social
pentru mobil pentru oamenii interesai de dezvoltarea personal i gndirea pozitiv, pentru a spune mulumesc i a-i aprecia prietenii extraordinari. Partea cea mai interesant era c profilul i va fi construit de ctre
prietenii ti care i dezvluiau punctele forte i faptele pozitive, dup cum
au fost vzute prin ochii lor. Am fcut puin cercetare, am derulat cteva
mici experimente care implicau aplicaii funny paper i stickies, am desenat
cteva cadre (wireframes). Dar la Startup Weekend Cluj, lucrurile au luat cu
adevrat vitez. Ne-am ntlnit cu nite oameni extraordinari. Ei au utilizat
codul i alte tipuri de magie pentru a aduce la via n dou zile, un prototip
funcional. Am ctigat locul al doilea mpreun i numai dou luni mai trziu, beta noastr public era lansat pe iOS i Android. Unii dintre noi am
lucrat doar part-time, nu ne-am vzut fa n fa n tot acest timp (deoarece
Mircea i cu mine eram n TechPeaks People Accelerator n Italia), i totui,
ne-am micat cu o vitez incredibil. O jumtate de an mai trziu, nc dezvoltm i rezolvm probleme mai mici sau mai mari mpreun. Avem mai
mult de 1200 de utilizatori beta i interes din partea unor investitori din UK
i Bulgaria, ceea ce ne-a fcut s avem o scurt prezentare la Facebook HQ
n Londra, recent.
LECII NVATE
Chiar dac oferisem consultan multor startup-uri i companii n legtur cu dezvoltarea produselor, ZenQ a fost prima mea ncercare n domeniul
mobil i de a conduce o echip de dezvoltare a produsului. Da, aceasta nseamn multe greeli i lecii nvate. i totui, mai nseamn i c, dac eti
pregtit s i le asumi, este mai uor ca niciodat s iei nite oameni deosebii
n echip i s ncepi un proiect propriu. Niciodat nu va exista un moment
mai potrivit, nu ai nevoie s tii nimic mai mult dect tii acum, vei nva
ceea ce trebuie pe parcurs. Partea cea mai grea este s perseverezi printre
eecurile multiple i s faci ca lucrurile s mearg i dup entuziasmul iniial.
Dureaz cel puin apte ani s construieti o afacere n IT care s poat fi
susinut global i nu exist o cale mai uoar. O ntrebare bun pe care s
i-o pui nainte de a ncepe Vreau s investesc urmtorii 10 ani din viaa
MANAGEMENTUL PRODUSELOR PENTRU STARTP-URI
63
mea pentru a face asta s funcioneze? Dac rspunsul este nu, s-ar putea ca
acesta s nu fie proiectul tu. Mai caut. Dac rspunsul e da, nu ai nimic de
pierdut dac ncepi chiar acum.
Urmeaz cteva dintre leciile pe care le-am nvat i care sper c vor
fi folositoare att colegilor startup-eri, ct i celor care se gndesc s construiasc un startup ntr-o zi. i poate, cine tie, managerii de produs care
i ctig din asta existena ar putea beneficia de o perspectiv diferit. nvturile se mpart n patru categorii, mentalitate, echip, proces i utilizatori- Cvartetul Sfnt al startup-urilor la nceput, dac dorii. Exist industrii
mari care se adreseaz problemelor legate de dezvoltarea personal, sudarea
i managementul echipei, procesele afacerii, marketing, fr a mai meniona
startup-urile. i totui, cnd vine vorba de Managementul produselor (Product Management) n contextul startup, exist cteva lucruri specifice pe care
s le avem n vedere, pe care vi le pot mprti din experiena mea personal.
Lectur plcut!
MENTALITATE
Dezvoltarea unui produs extraordinar ncepe din inim. Aici avem trei
puncte cheie. n primul rnd ceva simplu tu ar trebui s iubeti ceea ce
faci, deoarece numai o persoan fericit are perseverena s creeze lucruri
uimitoare. Totui, ar trebui de asemenea s iubeti i oportunitatea care vine
odat cu dezvoltarea produsului. Un produs nu are limit superioar n privina valorii pe care o poate aduce poi ajunge la sute de milioane de oameni
i le poi face vieile mai frumoase. Dac nu visezi la scar mare, dac nu eti
ndrgostit de aceast oportunitate imens, nu are nici un sens s realizezi
un produs. Poi fi mult mai fericit s lucrezi la altceva care este mai aproape
de inima ta s locuieti ntr-o cas n pdure, s cltoreti n jurul lumii,
s furnizezi servicii extraordinare oamenilor, orice. n final, dac nu eti sigur
c aceasta este ceea ce i doreti, nu uita c depinde de tine s faci alegerea.
Dragostea i pasiunea se construiesc, nu i se ofer gratis. Nu poi iubi pe
cineva de la prima vedere dragostea adevrat crete cu timpul i efortul pe
care l investeti n ea. La fel este i cu produsele. Stabilete-i un reminder
zilnic care s i aminteasc de ce faci asta i ce visezi s obii. i apuc-te de
treab. Dragostea ta va crete n fiecare zi. i odat cu ea i succesul tu.
64
Unde s i stabileti obiectivul? Buddha ofer un sfat foarte bun n legtur cu acest lucru. Imagineaz-i c desenezi o persoan pe o coal de hrtie
i apoi cteva cercuri concentrice n jurul su. Persoana aceea eti tu, cercul
cel mai apropiat este familia ta, urmtorul cerc reprezint prietenii ti, apoi
colegii, oraul tu, ara ta, lumea, etc. . Buddha spune c prin stabilirea unui
obiectiv mai aproape de ultimul cerc din desenul tu, tu generezi mult mai
mult energie n tine nsui, iar aceast energie te va ajuta s ajungi acolo. Aa
c fii curajos, nu te mulumi cu obiective care sunt mai prejos de visele tale
cele mai ndrznee.
Alege-i credina cu nelepciune. A aprut o ntreag industrie care ajut startup-urile s nainteze cri, evenimente, maetrii guru, acceleratoare. Toat lumea i ofer perspectiva sa despre cum ar trebui s i dezvoli
startup-ul, iar acest lucru este nemaipomenit. Este o bogie fr precedent
la ndemna ta, i totui este i un pericol. De exemplu, micarea lean este
nc pe val n timp ce vorbim. inei minte, totui, c marile startup-uri au
fost construite nainte de cartea The Lean Startup. i vor fi construite
mult dup ce trece acest val. Am ntlnit oameni care au progresat uimitor
urmnd aceast carte. i alii care au urt-o din tot sufletul i care i-au construit calea spre succes urmnd alte credine proprii. Soluia este s citeti din
rsputeri i s fii deschis la toate perspectivele, pn cnd faci alegerea ta legat de ceea ce s crezi. Am descoperit c este bine s fii puin schizofrenic
n legtur cu asta i s i dezvoli capacitatea de a avea puncte de vedere i
credine conflictuale n minte (ascult-i clienii i nu i asculta, planific-i
traiectoria i resursele financiare i nu le planifica, renun i persevereaz,
etc.). Nu tii niciodat care dintre ele va fi cea mai folositoare n urmtoarea
provocare pe care o vei nfrunta pe drumul tu.
Concentrare! Concentrare! Concentrare! Hai s fim serioi, nu poi
construi Microsoft, Apple i Facebook n acelai timp. Una dintre calitile cheie ale unui manager de produs este s spun nu. Dac nu i dezvoli rapid aceast capacitate, te vei pierde n fluxul de idei ale utilizatorului,
mentorului, echipei i propriile tale idei, nainte de a-i da seama. Lista de
funcionaliti ale produsului tu actual va continua s se extind pn cnd
va exploda i se va transforma ntr-o gaur neagr, din care nu va mai iei
nimic niciodat. Totul pornete de la tine i de la nceput dac viaa ta este
o harababur de proiecte, vei avea o harababur n fiecare dintre proiecte.
65
Alege unul i concentreaz-i toat energia i atenia pe acesta.

Greeli ZenQ, vol. 1: Acum e rndul meu s admit o greeal poate
voi o vei putea evita. Iniial, am presupus c restul echipei noastre va dori
aceleai lucruri ca i mine, c vom avea mentaliti asemntoare. Greit.
Mi-a luat ceva timp s neleg c fiecare dintre noi avea prioriti diferite,
obiective i planuri diferite i s m adaptez la situaia asta. Fiecare dorete s nvee i s se dezvolte n propriul su fel i are propriile sale motive
pentru a participa la proiectul tu. Scopul tu nu este s i faci s se alture
forei ntunecate sau aa ceva, ci s i nelegi. Diferenele dintre voi sunt o
binecuvntare deghizat cu ct suntei mai diferii, cu att mai bine pentru
startup-ul vostru. Cei care nu sunt de acord cu tine, cei care au ca prioritate
altceva n acest moment, cei care vor s fac multe lucruri, aduc o grmad
de experien i perspective diferite la masa de lucru. Acesta este un beneficiu
extraordinar oricnd ai nevoie de o metod creativ de a soluiona o problem cu care te confruni, ceea ce se ntmpl n cea mai mare parte a timpului.
ECHIPA
Pur i simplu, ai ncredere n ei. Oamenii care se implic n startup-uri
sunt extraordinari, i cnd le dai mn liber, ntotdeauna te vor surprinde.
Exist multe exemple n acest sens, n experiena mea. Claudiu, care acum
este dezvoltatorul nostru backend, nu avea idee de Python (tehnologia pe
care o utilizm) i iniial nu a avut un rol clar n echip. O lun mai trziu,
a vzut c avem o lips pe partea de backend, a nvat s scrie cod n Python
i a nceput s execute n mai puin de dou sptmni. Mihai, care lucreaz
la iOS, s-a oferit voluntar s prezinte proiectul nostru n TSM i s ne ajute
cu interfaa de nscriere a utilizatorului. Cristi a jucat un rol important iniial
n definirea a ceea ce trebuia fcut n termeni tehnici i mai trziu s-a oferit
s fac aplicaia noastr Android (nu avea experien n domeniul mobile).
De asemenea, ajut mult s nu te amesteci n cod ai ncredere n bieii de
pe partea tehnic c vor face ca totul s mearg. Treaba ta este s te asiguri
c produsul final funcioneaz dup cum ai discutat. Cum se ajunge la acest
lucru, este treaba expertului din fiecare domeniu.
Dinamica succesului. Acesta este singurul aspect pe care milionarul pe
care l-am menionat la nceput l cuta la o echip. Formarea ta, experienele,
66
potenialul nu conteaz. Singurul lucru care conteaz este s i dai gata pe

ceilali mpreun, s ai dinamica succesului. Echipa ta fie se mpac sau
nu se mpac, iar aceasta e vizibil chiar de la nceput. Mi-a spus c vzuse
oameni extraordinari care au euat n lucrul mpreun n cteva startup-uri
pe care el le-a creat, dar i anumite combinaii destul de ciudate de oameni
care acionau magic asupra altora. Cum se spune, echipa A este mai bun
dect un grup de juctori A. Nu are sens s analizm motivele, pur i simplu aa se ntmpl. Cnd drumul devine dificil (ex. pstrarea utilizatorilor
fideli nu este chiar pe roz, precum i-ai dori), tu ai nevoie de energia, creierul
i creativitatea tuturor pentru a defini paii urmtori. Creierul tu nu poate
egala niciodat creierul colectiv al 2-5 persoane diferite care vor s fac ceva
s funcioneze.
Funcioneaz echipele dispersate? i nc cum! Cu Skype/Google Hangouts, Trello i Google Drive, orice este posibil. Noi am livrat primul nostru
MVP dup dou luni de utilizare a acestora pentru a comunica ntre Cluj i
Trento (Italia) , i a funcionat mai bine dect oricare echip offline cu care
am lucrat vreodat. Atunci cnd oamenii vor s fac ceva, o fac i nu gsesc
scuze. O echip dispersat nseamn c oamenii lucreaz cnd vor ei (fr
a atepta s te aduni laolalt pentru a face ceva), ei pun ntrebri i primesc
rspunsuri rapid, fr a avea nevoie de contact direct, totul poate fi cutat i
realizat n timp ce vorbeti. Ceea ce este important e c managerul de produs
este ntotdeauna disponibil pentru a discuta deciziile/problemele importante
i pentru a se asigura c toat lumea se ntlnete suficient de des pentru ca
s poat exista colaborarea.
Greeli ZenQ, vol. 2: Nevoie de mai mult bere. mi doresc s fi numit un Ofier ef pentru Butur la nceput. Este inconvenientul echipelor
dispersate exist pericolul s te concentrezi pe munc i este mai greu s
i organizezi activitile care nu au legtur cu munca. Inclusiv, n primul
rnd, butura, de unde, pe lng rsete i istorii personale, se nasc multe idei
grozave. Aceasta nu poate fi imitat online. Ar fi nemaipomenit dac o parte
din echip care se afl ntr-un loc s-ar ntlni n mod regulat. n orice caz, ce
putei face este s ncercai s v ntlnii fa n fa mcar o dat pe lun,
dac se poate. Merit cu vrf i ndesat!
67
PROCESUL
Nu planifica drumul. Exist o tendin natural s vrei s ai totul clar
dinainte s ncepi. Totui, adevrul este c n primele luni ale proiectului tu,
nainte de a ajunge la potrivirea produsului cu piaa, ideea ta se schimb constant. Este un proces aleatoriu un coleg de echip tocmai a avut o idee extraordinar n timpul implementrii, te-ai lovit de o limitare tehnic, ai aflat
despre un competitor care are o strategie interesant, un mentor i-a dat o
idee grozav despre capitalizare, ai citit Hooked i te-a lovit ideea c, pentru a reine utilizatorii, trebuie s ai notificri, e-mailuri care s le aminteasc
de tine. Exist un flux constant de modificri mici i simple care sfresc
prin a-i transforma produsul n ceva foarte diferit fa de ce ai avut n
minte cnd ai nceput. Deci ce poi face n aceast privin? Trei lucruri.
S ai un plan de cel mult cinci pai n minte (ex. s obii investiia, s aduni
echipa, s te mui n US, s obii un parteneriat cu Facebook, s faci minuni).
Dezvolt cu echipa ta o definire detaliat i foarte clar a funcionalitilor
pentru versiunea la care lucrai n prezent. i o idee general cu privire la
principiile/ valorile principale nspre care tindei cu produsul vostru, cu o prioritate clar pe care vrei s o abordai n urmtoarea versiune. Este suficient.
ncepe rapid i murdar. Eu sunt un mare fan al formatului Startup Weekend datorit culturii pe care o promoveaz chiar de la constituirea echipei
tale. Te face s te concentrezi pe vitez, execuie i distracie chiar din prima
zi toate elementele de baz ale unei culturi a startup-urilor de succes. Pe
lng asta, un weekend de munc intensiv mpreun spre un obiectiv clar
arat fiecrui membru din echipa ta ce nseamn s faci lucruri mpreun.
Fiecare dintre voi vede dac exist o dinamic a succesului n echipa voastr sau nu. ansele sunt ca s avei un mic ctig care va suda echipa i v va
motiva s continuai mpreun, ntr-o alt ncercare. Nu trebuie s ateptai
urmtorul Startup Weekend, multe startup-uri au weekenduri de lucru care
funcioneaz de minune. Ceea ce este important e ca tu, n calitate de manager al produsului, s fii foarte clar cu privire la cele 2-3 funcionaliti care
reprezint baza aplicaiei tale. Schieaz trei ecrane pe o bucat de hrtie i
asigur-te c toat lumea nelege, ofer feedback i este de acord cu ceea ce
tu hotrti c poate fi fcut. Cheia este s livrezi ceva mic i simplu, ct mai
curnd posibil.
68
Produsul minim viabil (MVP) nu este nici produsul minim atrgtor

(MLP) i nici produsul minim cumprat (MBP). Ok, deci acum echipa ta
este dornic s treac mai departe la urmtoarele etape i s realizeze ceva
mai mare. Din nou, gndii simplu i rapid i aici chiar i pentru cea mai
simpl definire de produs, vor exista att de multe lucruri care s mearg
prost nct nu va mai prea att de simplu. Cu ct este mai mare i mai complex, cu att crete probabilitatea ca echipa ta s oboseasc luptnd cu toate
acele probleme mici i s-ar putea s nu mai livrai niciodat. i, indiferent ce
construieti, indiferent ct de mult timp i-a luat i ct de mult ai vorbit cu
clienii nainte, exist o ans de 99% ca oamenii s nu se ndrgosteasc
de produsul tu atunci cnd l lansezi. Numai utilizatorii reali care folosesc
soluia ta zilnic, pe msur ce acordezi i testezi lucruri diferite cu ei, numai
ei te pot ndruma. Numai dup ce ai livrat MVP-ul i poi da seama care
este produsul tu minim atrgtor, care va fi acel set de experiene i funcionaliti care i face pe utilizatori s arate ca nite nfometai care revin mereu
la borcanul tu cu bunti. Odat ce ai descoperit asta, va fi n sarcina ta s
i dai seama care este produsul minim cumprat setul minim de lucruri
pentru care utilizatorii vor plti, astfel nct s te poi menine n afaceri i s
creti. Dac eti suficient de ambiios n visurile tale i ai succes n realizarea
acestei treceri graduale de la MVP la MBP, vei avea o estimare de sute de
milioane de dolari a startup-ului tu n acel moment. n etapa MVP, este
foarte important s stabileti ateptrile echipei tale. Lansarea voastr nu
va aduce mulimi de utilizatori care se vor clca pe picioare pentru a ncerca
produsul. Chiar dac ai avut un articol n TechCrunch sau ceva similar, vei
ncepe foarte bine, dup care utilizatorii vor nceta s mai revin. MVP-ul
vostru reprezint punctul de pornire n adevrata munc de gsire a utilizatorilor i de a-i face s rmn! i toat lumea din echipa ta ar trebui s fie
pregtit s fac fa situaiei.
Msoar totul de la nceput. Dac nu msori, nu nvei i nu ai un startup. Simplu. Dat fiind c MVP-ul tu este sursa ta de nvare, nu i poi
permite s nu pui parametri clari pentru ceea ce doreti s nvei, s i urmreti sptmnal, s efectuezi teste AB, s msori impactul fiecrei mbuntiri i funcionaliti noi. Nu este greu s implementezi aa ceva. Totui
i va lua o zi ntreag s te gndeti care vor fi indicatorii de performan
cheie (KPI) i ce alte lucruri vei msura la fiecare ecran/interaciune pentru
69
a-i permite s vezi de ce un indicator de performan nu este aa cum i

l-ai dorit tu s fie. Dac a putea s m ntorc n timp, m-a asigura c am
implementat nu numai Flurry, dar i MixPanel, Localytics, Google Analytics
pentru mobile. Astfel, poi s vezi uor tot ce poi face cu acestea i poi alege
ce e mai potrivit pentru tine. Altfel, sfreti prin a visa la anumite informaii
(cum ar fi comportamentul utilizatorului individual sau abilitatea de a trimite e-mailuri pe baza acestuia) i a atepta urmtoarea lansare pentru a le
obine. Aceasta te ncetinete fr motiv.
Paznic la o turm de iepuri. Cteva cuvinte despre organizare. Agile este
baza, dar fii ateni cum implementai aceste principii. Scopul este s funcioneze pentru voi i nu voi s muncii pentru aceasta. Luai ce avei nevoie,
experimentai i observai ce impact are asupra muncii voastre. Pentru noi,
trei lucruri au funcionat precum magia. Sprint-urile un volum specific de
munc care produce un produs testabil pentru o perioad dat (o sptmn, 2, 4 sptmni). Trello este extraordinar pentru aa ceva trebuie doar
s descompui MVP-ul tu n funcionaliti, s decizi la care dintre ele s
lucrezi n primul tu sprint, s o divizezi n sarcini pentru toat lumea din
echip (ex. UX, backend, iOS, Android) i poi porni la drum. Al doilea element Agile user stories aa defineti fiecare sarcin n Trello: ca utilizator
(nceptor), doresc s (vd X pe profilul meu), astfel nct s pot (face Y).
Aceasta face minuni cu privire la ct de bine nelege toat lumea ceea ce
construieti i poate rezolva problemele pe parcurs. i n final scrum-uri
regulate: ntlniri scurte n care fiecare rspunde la trei ntrebri: ce am fcut
n ultima perioad?; ce probleme am avut?; ce vreau s fac n continuare?.
Acestea v ofer un ritm de lucru regulat, un loc n care s cerei ajutor,
s discutai, s rezolvai probleme mpreun, s fii la curent cu ce fac toi
ceilali. E foarte important!
Greeli ZenQ, vol. 3: Iniial, am dat gre cu durata sprint-urilor. Toat
lumea lucra part-time i totui am lucrat cu sprint-uri lungi de 1-2 sptmni, ceea ce i extenua pe bieii de la tehnic. Acelai lucru se aplic i la
Scrum iniial, ne ntlneam mult prea des (la fiecare dou-trei zile), pierznd timpul cu discuii lungi care urmau fiecrei sesiuni de scrum. Ne-am
mulumit apoi cu sprint-uri lunare i scrum-uri sptmnale, care par a fi cele
mai potrivite n cazul nostru. Aceste durate pot face diferena dintre un bici
i o tob ntre ceva care te streseaz i i duneaz vieii i ceva care doar
introduce un ritm n vslitul echipei tale. Conteaz.
70
UTILIZATORII
ntreab-i i nu-i ntreba utilizatorii. Nu este o coinciden c am lsat
utilizatorii pe ultimul loc aici. Valoarea pe care ei o percep din ceea ce faci
este singura metod de a aprecia ct de bine funcioneaz mpreun mentalitatea ta, echipa i procesul. Dac faci bine lucrurile, ei sunt o surs uimitoare
de nvare, inspiraie i motivaie pentru a merge mai departe. Ai nevoie de
o baz pe care s construieti, iar aceast baz este ceea ce vrei s faci, mentalitatea ta, echipa ta i procesele. Aezi baza la locul ei i continui s primeti
feedback de la utilizatorii ti pentru a te asigura c creezi experiena pe care ei
o doresc. n detaliu, nu dac este o cas sau o nav spaial. De multe ori, utilizatorii i vor spune un lucru, iar atunci cnd au produsul n mn vor face
cu totul altceva. Vei auzi sute de idei n legtur cu ce ar trebui mbuntit.
Sute de idei despre cum poate fi aplicat n cazuri diferite de utilizare. Atunci
cnd primeti feedback cantitativ, acesta va fi bazat fie pe ceea ce exist deja,
fie nu va fi suficient de profund pentru ai construi viziunea produsului n jurul su. Cnd primeti feedback calitativ, acesta va fi nesemnificativ din punct
de vedere statistic, zgomotos i greu de sintetizat. Nu te poi baza pe utilizatori ca s i spun care ar trebui s fie viziunea produsului tu. Te poi baza
pe ei s te corecteze pe parcurs, s i ofere idei despre funcionaliti cool i
s te ajute s nvei. Ascult-i n legtur cu acestea!
50% dintre oameni nu vor nelege. Dac eti norocos. i cel mai probabil aceti oameni nu sunt inta ta depinde de tine s i dai seama de ce,
acest lucru te va ajuta s te orientezi mai bine nspre ceilali %50 rmai.
ntreaga afacere Red Bull este creat n jurul a %50 dintre utilizatori, crora
le place. Restul oamenilor ursc chiar i gustul su, dar asta nu mpiedic Red
Bull s fac miliarde de la primul grup. Nu i poi mulumi pe toi, aa c cel
mai bun pariu al tu este s te concentrezi pe punctele luminoase. Acetia
sunt utilizatorii ti fideli, cei care iubesc ceea ce faci tu i care vor s te ajute
s mbunteti produsul. Privind la experienele lor uzuale cu produsul tu
(cum arat fluxul lor exact, pas cu pas), tu poi observa tiparele i i poi
dezvolta interfaa utilizatorului astfel nct s i ncurajezi i pe ali utilizatori
s fac aceiai pai. Pentru asta, ai nevoie de analitic la nivel individual (ex.
oferit gratuit de MixPanel).
71
Experimenteaz din rsputeri. Ajut s ncepi ntotdeauna cu cteva experimente offline (ex. noi am fcut un test al aplicaiei pe hrtie cu 30 de oameni nainte de a construi ceva). Chiar i mai trziu, este bine s experimentezi nainte de a construi funcionaliti noi majore. Aici cheia este s observi
comportamentul mai degrab dect opiniile. Nu explica, urmrete! i din
nou are sens numai dac msori. Imagineaz-i care ar fi comportamentul
ideal pe care ai vrea s l vezi, mparte-l n buci mai mici, gndete-te la
o metric pentru fiecare etap, stabilete o norm pentru ea i vezi cum se
compar rezultatele reale cu aceasta. Pe msur ce avansezi cu MVP-ul tu,
f ct de multe teste A/B poi pentru copia ta, pentru butoane, culori, flux,
etc. . Exist cteva instrumente grozave pentru aceasta, chiar pentru mobile
(ex. noi folosim Vessel). Vei gsi muli biei care construiesc nc astfel de
soluii, care se afl ntr-o etap timpurie i sunt dispui s negocieze preurile
n schimbul feedback-ului. Folosii-v de asta.
Nu explora, persist. Una dintre cele mai mari nenelegeri legate de
micarea lean este despre termenul validare. Iar i iar vedem oameni care fac
dezvoltarea clienilor, ncercnd lucruri pentru a vedea cum funcioneaz.
Apoi spun c nu au primit validare, drept o scuz pentru a renuna la un
proiect dup ce au fost demotivai de rezultatele timpurii descurajatoare sau
disfunciile iniiale ale echipei. Primele semne de validare real au loc atunci
cnd abordezi reglarea produs-pia. Dac dezvoli ceva apropiat de o soluie
existent cu o uoar zvcnire nou, aceasta se poate ntmpla rapid (dac ai
un plan solid pentru a te diferenia de competitori). Dac faci ceva mai inovativ, i va lua multe iteraii (i noroc) s ajungi acolo. Dac vei renuna de la
primul hop din drum, ce rost mai are s ncepi? Dac produse ciudate cum
sunt Snapcat sau Yo pot ajunge la milioane de utilizatori, ideile proaste care
nu pot obine dragostea utilizatorilor pur i simplu nu exist. Totul ine de
execuie. S faci sau s nu faci. Nu exist ncercare.
Greeli ZenQ, vol. 4: Iat una pe care nu am rezolvat-o nici pn n ziua
de azi nu am pstrat relaiile cu utilizatorii suficient de apropiate. Nu vorbesc de postarea unor poze cu pisici drgue pe Facebook, ci despre ceea ce se
ntmpl DUP ce un utilizator vine la tine cu feedback i idei. Este sarcina
ta s menii acea relaie, s implici persoana respectiv mai mult, s i ari
dragostea ta i s obii ajutorul su pe parcurs. Necesit efort s construieti
72
acest proces, s defineti ce s ntrebi/discui n fiecare sptmn i s faci

conversaia s continue. Am ajuns la concluzia c acest aspect este de fapt un
rol n sine, pe care ar trebui s l aib chiar de la nceput cineva din echipa
ta, care s fie clar rspunztor pentru aceasta. Nu toi cei 500 de oameni care
i-au scris s i spun ce le place sau nu le place n legtur cu beta ta atunci
cnd a fost lansat, vor avea timp s discute n continuare. Dar cei 20% care
o vor face, sunt mai mult dect suficieni pentru a te ajuta cnd testezi lucruri
noi i te ndrepi spre ajustarea produs pia.
CONCLUZII
n acest articol am artat c, dac eti o fat de 25 de ani fr nici un
pic de experien n dezvoltarea produselor, nimic nu te poate mpiedica s
schimbi acest lucru. Acelai lucru este valabil i pentru voi, oriunde ai fi i
oricare este experiena voastr. De fapt, lumea ntreag i progresul nostru ca
i umanitate depinde de voi s riscai, s ieii din zona voastr de confort i
s facei ceva ce alii nu au mai fcut pn acum. Probabil c vei pierde, dar
dac inspirai pe altcineva s v urmeze i el/ea reuete, milioane de oameni
s-ar putea s o duc mai bine n civa ani. Ce ai putea dori mai mult?
Leciile mprtite aici s-au adresat celor care sunt la nceput de drum
i s-au referit la mentalitate, la cum s i construieti o echip, ce procese s
urmezi i la cum s comunici cu utilizatorii. Acestea sunt n ntregime supuse
criticii, discuiilor i interpretrii din partea voastr. Poate c am greit n
totalitate n legtur cu unele dintre ele i voi afla aceasta sptmna viitoare
sau mine. V doresc s mi descoperii greelile pe msur ce avansai i
facei propriile voastre greeli (dac deja ai gsit cteva, tii despre ce vorbesc).
Dac exist ceva ce ar trebui s reinem, sper s fie o mic mantra pe
care am nvat-o de la tipul din Israel care a fcut minuni pentru mine.
Este o replic simpl pentru a-i nva subcontientul care ar trebui s fie
atitudinea ta fa de toat nebunia care te ateapt n legtur cu startup-ul.
73
Alege un moment din zi (poate dimineaa, poate nainte de evenimente sau

ntlniri importante, etc.) n care s te priveti n oglind i s spui: Eti o
persoan extraordinar. Poi face orice. i te iubesc. i apoi iei n lume
i f minuni.
V mulumesc! ZenQ!
Autor
Zornitsa Tomova - Cofondator @ ZenQ
Sergiu Damian
Sergiu Damian este un architect software experimentat, cu o profund

nelegere a designului software, practicilor i proceselor de dezvoltare i, nu
n ultimul rnd, al dinamicii umane din echipe. Dup 13 ani petrecui n
diverse roluri n companii locale de outsourcing a ales s devin un arhitect
software independent, ajutnd diveri clieni n a-i atinge succesul. Este activ n comuniti IT, ofer asisten studenilor i i inva pe alii despre
software architecture.
8
ARHITECTUR PENTRU
STARTUP-URI. PROVOCRI I DECIZII.
n ce fel arat rolul arhitectului care particip ntrun startup? Aa cum

un birou mare de arhitectur va face extrem de rar o csu de locuit, atunci
cnd poate s i pun numele pe o sal polivalent, la fel n firmele mari
de software, chiar specializate n outsourcing, avem dea face de obicei cu
aplicaii de tip enterprise. Cerinele se discut n edine care implic reprezentani de la client, att tehnici ct i din domeniul funcional, iar discuiile
sunt centrate pe nelegere ct mai precis. n procesul dezvoltrii aplicaiilor,
arhitectul ia decizii sub presiunea unor factori multipli de calitate, a efortului
i a altor constrngeri.
Valorific experiena recent care mia artat un proces similar derulat
ntrun startup i v propun s analizm mpreun cum sa schimbat demersul i rolul de arhitect n acest context.
Dup aproape cincisprezece ani petrecui ca dezvoltator, arhitect sau
manager n firme de outsourcing clujene, am primit recent o provocare nou
din partea unui prieten. Visul lui e de a realiza o suit de aplicaii mobile
care s ajute pe utilizatorul potenial s i mbunteasc calitatea general
a vieii. Rugmintea lui a fost s fiu eu arhitectul, omul care gndete partea
tehnic pentru acest ecosistem. Am acceptat fr s clipesc. De ce? Mam
ntrebat adesea ce e diferit ntrun context de startup comparat cu mediul
76
enterprise cu care eram obinuit eu. Echipa sa n acel moment nu avea niciun programator. Era format doar din oameni care dezvoltau un concept, o
idee, un alt fel de a ajuta oamenii. Pentru mine era o noutate i din punctul
de vedere al coninutului era vorba de o suit de aplicaii departe de zona
obinuit de aplicaii de prelucrare a datelor care, ntrun fel sau altul, faciliteaz diverse procese din mediul enterprise.
V invit n continuare s vedem mpreun cum a decurs micul nostru experiment oprindum mai apsat asupra a trei decizii, care cred c ilustreaz
cel mai bine diferena ntre stilul de lucru i arhitectura de startup fa de
cea din mediul corporativ.
COMUNICAREA
Prima constatare a fost c n echip nu exista o imagine clar asupra a
ceea ce vrem s realizm, dar exista dorina acut s avem ct mai repede o
prim aplicaie. Aa c, dei unii ar spune c asta nu e treaba arhitectului,
am reformulat complet modul de lucru. Am stabilit c, dac nu vorbim toi
aceeai limb, nu avem cum s fim coereni, s nelegem despre ce vorbim i
unde vrem s ajungem. Dei instinctul ne mpingea s pornim ct mai repede
construcia tehnic, neam dat repede seama c nu tim suficient i c am
cheltui efort mult, cu riscuri mari de a da gre.
Pare banal, privind n retrospectiv, ns e extrem de important s gsim
mijlocul potrivit de comunicare, de a nota ideile ntrun mod uor de neles
pentru toi, ct mai vizual i ct mai aproape de realitatea nconjurtoare.
Aa c, am folosit unelte de creat schie ale interfeei cu utilizatorul. Echipa de concept a adoptat rapid acest stil i, mai mult, a ales singur unealta
potrivit, trecnd de la Balsamiq (folosit iniial) la Indigo Studio. n scurt
timp, toat echipa adoptase acest limbaj i ideea ne era tuturor din ce n ce
mai clar. ntlnirile noastre au devenit mai eficiente, structura aplicaiilor
devenea clar, ne era uor s ne imaginm cum vor funciona i chiar ce ar
putea simi un utilizator.
n ultimii ani, uneltele specializate pentru crearea i editarea (unele permit chiar rularea) schielor de aplicaii (n englez mockups sau wireframes)
au evoluat n calitate, flexibilitate i uurin n utilizare. A ndrzni s spun
c oricui cu sau fr studii de IT, iar fi acum la fel de uor s creeze schie
de aplicaii ca i cum ar edita un document oarecare. Aadar, orice proiect
77
software poate ncepe acum cu o schi.

Cred cu trie c arhitectul ca liant ntre funcional i tehnic poate i chiar
are datoria s ajute ntreaga echip i nu doar partea ei tehnic. Pn la urm,
i arhitectura echipei e tot o arhitectur, nu? Am mai ntlnit i n lumea
proiectelor de mari dimensiuni ncercri de a desena aplicaia nainte de a
ncepe implementarea ei, ns, de multe ori, proiectul e att de mare nct
efortul pare gargantuesc sau chiar zadarnic. Chiar i atunci, a zice c a schia
esena aplicaiei sau prile ei mai interesante ajut n comunicare, iar comunicarea face ca mecanismele proiectului s se potriveasc mai bine.
CALITATEA
A doua provocare de care mam lovit a fost smi redefinesc ateptrile
tehnice. Eram obinuit s analizez n detaliu cerinele clientului (adesea o
organizaie reprezentat de civa indivizi) legate de performan, scalabilitate, securitate, adaptabilitate i alte astfel de atribute (rspund la ntrebarea
Cum?), n plus fa de cele strict funcionale (rspund la ntrebarea Ce?).
Miam dat seama c viitorul utilizator al aplicaiilor create de noi va avea
cu totul alte criterii de judecat, cele mai importante fiind, foarte probabil,
valoarea adus lui i uurina n utilizare (efortul depus pentru a obine acea
valoare).
mpreun cu echipa, am decis c n contextul nostru e mai important
s aducem aplicaia n faa utilizatorilor dect s rspundem acum tuturor
ntrebrilor posibile despre calitate. Am ales, astfel, n cunotin de cauz i
asumndune investiii ulterioare, s implementm aplicaia folosind cea mai
simpl soluie tehnic, dar extensibil ulterior. Nu voi intra acum n detaliile
tehnice, pentru c acelai raionament sar putea aplica oricrei combinaii
de platform i limbaj de programare.
Ne lovim frecvent, mai ales dac suntem obinuii cu proiecte sau produse
software de dimensiuni mari, de dificultatea definirii calitii. A gsi echilibrul perfect ntre calitatea i puritatea tehnic, viteza i costul dezvoltrii i
momentul ieirii pe pia e un aspect dificil de gestionat. n mediul enterprise,
calitatea are impact major n costul total al deinerii i operrii unui sistem
(TCO). Fr s am nite statistici precise, costul calitii e adesea mai mare
dect costul direct al producerii funciilor produsului. Ca outsourcer-i, neam
dori calitate maxim la costuri minime, deziderat care e adesea doar un tru-
78
ism imposibil de atins.

Dar n context de startup avem libertatea s alegem. Clientul nu e o
firm mare ci sunt (n cazul nostru) miliardele de posesori de dispozitive
mobile de pe glob, deci nu ne e imediat vizibil i accesibil. Nu l cunoatem,
ci doar ne imaginm c i dorete acelai produs pe care l vism noi. Aadar, singura modalitate de a interaciona cu clientul i de a afla dorinele
sale este de ai pune la dispoziie aplicaia i a colecta feedbackul su. Dac
aa stau lucrurile, atunci e mai degrab important s lansm produsul, chiar
dac e incomplet sau la un nivel de calitate mai sczut, dect s ncercm s
atingem perfeciunea, s respectm toate regulile dar s riscm s aflm prea
trziu c produsul nostru nu satisface nevoi reale sau nu atinge ateptrile
utilizatorilor.
Sunt faimoase cazurile Gmail, Flickr i alte cteva care au fost lansate i
apoi pstrate n form neterminat (n programare cunoscut sub numele
de beta) ani de zile. Motivul este unul legat de gradul de satisfacie al echipei de dezvoltare legat de starea produsului, nicidecum de calitatea lui sau
abilitatea de ai deservi utilizatorii.
n cazul nostru, am decis s renunm deocamdat la unele aspecte ce in
de calitatea serviciilor de pe server (calitate pur tehnic) ca s putem investi
mai mult n calitatea experienei utilizatorului. Citind povestea lui Jeff Bezos
i a Amazon (aprut n limba romn la editura Publica) ntlnim relatri
picante ale reversului medaliei, i anume efortul necesar de a suplini aceste
compromisuri atunci cnd succesul te lovete n mod neateptat.
PLANUL
Odat stabilit modul de comunicare n echip i de documentare a inteniilor noastre, puteam s demarm construcia. Neam dat seama dup
primele estimri c efortul necesar, raportat la timpul disponibil era disproporionat. Aceast disproporie se ntea din faptul c fiecare dintre membrii
echipei folosete pentru a participa o felie limitat de timp personal. Am
decis, cum menionam mai devreme, s renunm la unele aspecte tehnice.
Cu toate astea, complexitatea nu poate fi eliminat complet. A face software
nu e lucru simplu. Astfel, am ntlnit o a treia provocare. Aceea de a planifica
munca ntregii echipe (incluznd aici concept, design grafic i dezvoltare)
n aa fel nct s reducem timpul nefolosit i s maximizm viteza cu care
79
mergem cu toii nainte.

De data asta mia fost mai uor. Reveneam ntro zon familiar. Mi se
prea chiar mai simplu dect ntrun proiect mare, pentru c vorbeam de o
echip mai mic, de funcionaliti mai puine i dependine mai clare. Am
stabilit aadar mpreun cu echipa, c vom adopta strategia plugurilor de
zpad care bat prtiile sau cur iarna pista unui aeroport nzpezit. Vom
decala ciclurile n aa fel nct echipa de concept s fie cu un pas naintea
celei de design, respectiv echipa de servicii (backend) s fie cu un pas naintea celei de aplicaii. tiu, vei zice c e la mintea cocoului, ns a atinge
ritmul corect i a gestiona patru fire diferite nu e chiar uor pentru cel ce
joac rolul de manager de proiect. n plus, nu e chiar evident ce nseamn a
fi cu un pas naintea celuilalt. Noi am decis c finalizm toate cele necesare
celeilalte echipe pentru a putea lucra fr ntrerupere de mari ncolo (orice
zi a sptmnii e la fel de potrivit pentru acest scop). Important e ca toi s
nelegem i s dansm acelai stil de vals.
Una din responsabilitile arhitectului software este de a defini calea spre
atingerea succesului dorit. Adesea, n proiectele enterprise, nu se poate estima
sau planifica fr ca arhitectul s fie cel puin consultat. i asta pentru c
soluia tehnic aleas (pentru care arhitectul este responsabil) influeneaz
major costurile, planul, etapele i durata realizrii produsului.
Dar sunt multe alte variabile, dincolo de soluia tehnic, care influeneaz
realizarea unui proiect software: experiena echipei, condiiile de lucru, uneltele de care dispun, implicarea clientului, gradul de motivare, uneori chiar i
vremea de afar. Cum unele dintre ele nu sunt controlabile sau chiar predictibile, influena lor crete complexitatea proiectului.
Complexitatea inerent produselor software e att de mare nct Uncle
Bob (Robert C. Martin , un faimos consultant software i autor de cri) a
postulat n una din crile sale c e imposibil de estimat i planificat corect
munca mai departe de dou sptmni. Totui, e posibil s nelegem etapele
mari, dependinele i ordinea n care s construim, avnd o estimare aproximativ suficient de bun pentru a putea gestiona ateptrile clienilor n
baza ei.
E dificil s fii flexibil, deschis i curios i s abordezi situaia liber de
constrngeri, atunci cnd miza proiectului, msurat financiar este mare. De
obicei, n firmele mari se lucreaz cu miz mare i toi ne dorim cteodat s
ne vedem numele pe o sal polivalent. Ceea ce am aflat sau miam reconfirmat, e c, indiferent de rolul avut n echip, merit cteodat s dezvoli
80
i o csu de locuit, mcar pentru bucuria de a reveni la resurse minime i

libertate maxim.
Not: Suita de aplicaii despre care vorbim este nc n dezvoltare, ne
apropiem cu pai mari de prima lansare, de prima aplicaie n versiune beta.
Deocamdat ne sincronizm i nc nu a cerut nimeni din echip s schimbm formula. Dac vrei s ne urmreti, o poi face aici:
http://moodtracker.giminiapps.com/
Autor
Sergiu Damian - Independent Software Architect
81
Silvia Rusanu
Silvia este o tnr pasionat de IT, interesat de big data i de inteligen

artificial.
Silvia este combativ i este aproape un hazard s o contrazici.Aadar
,dac porneti o polemic, trebuie s fii narmat cu argumente puternice bazate pe fapte.
A nceput s lucreze n ISDC acum patru ani ca junior developer. De atunci a avut un parcurs interesant, acum fiind unul dintre experii n big data,
modelare de date, procesare de date i nvare automat din ISDC. Pe lng
pasiunea ei pentru acest domeniu, Silvia ine prezentri la conferine, scrie
articole de specialitate i ofer training-uri.
Silvia a terminat Facultatea de Matematic i Informatic la Universitatea Babe-Bolyai, Cluj-Napoca, n 2010, iar n 2012 a absolvit masterul
Sisteme Inteligente la aceeai universitate.
9
SURSE DE PRESIUNE
A fost odat ca niciodat o companie cu o afacere interesant; compania avea un grup devotat de oameni de afaceri care urmreau dezvoltarea
produsului lor pentru a ndeplini necesitile clienilor lor, dar i pentru a-i
menine nivelul veniturilor lor la cel mai bun nivel posibil. De asemenea,
compania avea i un departament tehnic, plin de ingineri i analiti talentai
care fceau ca visele i planurile afacerii s devin realitate, i care, n acelai
timp, erau mulumii i suficient de incitai de munca lor. Acest basm a durat
o vreme ndelungat: datele, instrumentele, procesele erau toate acolo pentru
a menine lucrurile i pentru a mpinge afacerea pe calea succesului. Totui,
nimic nu dureaz pentru totdeauna. Nici lumea afacerilor i nici cea a IT-ului nu stau pe loc. Odat cu creterea exponenial a Internetului i a accesului
pe care oamenii l au la tot felul de resurse online, un fel de domino a fost pus
n micare, iar compania a nceput s simt presiunea.
Datele din jurul afacerii erau ateptate s creasc liniar n volum, an dup
an, conform modului n care au fost iniial proiectate . Baza de clieni era n
continu expansiune, dup cum la fel erau i preteniile lor. Furnizorii de date
au suferit o cretere asemntoare, fiind capabili s livreze cantiti mult mai
mari de informaii. Procedurile dedicate procesrii datelor au fost construite
pentru a fi scalabile doar pentru un anumit volum, dar acum acestea nu mai
par potrivite i, cu siguran, nu mai sunt suficient de performante. Presiune!
84
n jurul lumii, un graf social imens a nceput s se formeze bazat pe platforme precum Facebook, Twitter, Yelp, Youtube i preaputernicul Google.
Utilizatorii i exprim cu mai mult libertate opiniile, ofer feedback imediat
pentru produsele pe care le folosesc, i modeleaz personalitile lor online
prin exprimarea antipatiilor i a preferinelor. O abordare avnd n centru
produsul, cu o linie de suport pentru clieni este de domeniul trecutului;
lumea afacerilor se reorienteaz ctre o perspectiv orientat spre client. Clientul i dorete ca lucrurile s fie personalizate doar pentru el i s nu piard
timp cu informaii inutile. Compania nu a prevzut aa ceva, iar acum trebuie
s gseasc o soluie care s ncorporeze toate aceste forme de date n afacerea lor. Presiune!
Tehnologia avanseaz ntr-un ritm rapid i i face apariia n locuri
neateptate: camere video pentru control, senzori de greutate, senzori pentru
trafic, etc.. Clienii ar aprecia cu siguran informaiile care le-ar putea uura
viaa ct timp sunt offline; totodat, compania ar beneficia de cunoaterea
comportamentului clienilor lor pentru a lua anumite decizii. Totui, produsul afacerii nu este pregtit pentru date ce vin cu vitez att de mare.
Presiune!
Oamenii tehnici din companie erau satisfcui cu munca lor i erau la
curent cu tendinele tehnice. Dar ei aud tot mai des despre big data, i nu
mai sunt att de fericii pentru c nu au ocazia s lucreze cu cele mai noi instrumente despre care vorbete toat lumea: NoSQL, Hadoop, etc.. Presiune!
Dac abstractizezi povestea companiei de basm, chiar poi vedea presiunea generat de volumul, varietatea, viteza i multitudinea de instrumente
generate de big data. Cu aceast presiune se confrunt oamenii de business i
cei tehnici. Citind printre rnduri, devine evident c numrul de lucruri ce
trebuie luate n considerare cnd ndrepi un proiect n zona big data nu este
neglijabil, iar presiunea este mprit ntre cei ce iau decizii att pe partea
de business, dar i pe cea tehnic. Nu exist reete care s rezolve tot, dar
sunt principii de considerat i ntrebri de pus nainte de a ncepe cltoria
de eliberare a presiunii big data. Cteva dintre aceste reete vor fi prezentate
n seciunile urmtoare.
85
ELIBERAREA DE SUB PRESIUNE PERSPECTIVA BUSINESS

Ca om de afaceri, trebuie s nelegi ce i pot oferi datele din jurul aplicaiei tale precum i unde este loc de mbuntire a experienei clientului,
deci i a veniturilor tale. Apoi s te pui pe treab.
Cu toate acestea, nainte de a te ndrepta n direcia big data, trebuie s te
asiguri c celelalte date - small data - sunt n ordine. n orice afacere, stagnarea veniturilor sau a bazei de clieni, etc., sau, mai ru, declinul acestora, se
poate ntmpla, dei nimic notabil nu s-a schimbat astfel nct s afecteze
domeniul afacerii sau clienii. Ai putea s crezi c folosirea big data ar putea
s-i ndeprteze de aceast cale descendent, dar ar fi mai bine ca mai nti
s verifici integritatea i stabilitatea sistemului nainte de a trage vreo concluzie. Dac serviciul pentru clieni tot primete plngeri pe acelai subiect
i, chiar dac angajaii pot rezolva problema foarte repede, poate ar fi cazul
s aloci timp pentru a elimina rdcina problemei, n loc s investeti n mod
repetat efortul minim pentru a corecta efectele. Dac n cadrul proceselor
este un pas n care consistena trebuie rezolvat prin aciuni manuale de
alterare - schimbare de status n baza de date, rularea recurent a unor proceduri pentru a corecta datele - atunci ar trebui s investeti n automatizarea
acestor procedee, n loc s fie fcute la cerere. Acest tip de comportament
n relaia business-IT denot c starea small data nu este bun, iar adugarea
mai multor date (mai puin structurate dect cele existente) va aduce doar
mai multe pagube i mai puin fiabilitate. Avnd aceste premise ndeplinite
pentru small data, poi face big data.
Ca persoan de business este foarte important s ai imaginea de ansamblu
a direciei n care te ndrepi, dar nu trebuie s te atepi c implementarea
ntregii tale viziuni s fie la fel de rapid ca i crearea unui plan. Chiar mai
mult, nu te atepta ca utilizatorilor s le plac schimbarea la fel de mult cum
i place ie. Dac ar fi s propun o reet ca oamenii de afaceri s profite de
trendul big data, urmtorii pai ar sumariza-o.
1. Analizeaz direcia de business i identific problema pe care vrei s
o rezolvi folosind big data. Nu sri ctre un trend tehnic - big data fr s ai un caz concret pentru aplicaia ta. ncearc s cuantifici (ipotetic) succesul ideii tale - va mbunti satisfacia clienilor ti? va
mbunti retenia de clieni? i va crete veniturile? este un procent
86
care merita efortul?

2. Din problema identificat, taie o felie vertical pentru rezolvare.
Partea aleas va fi reprezentativ pentru noul produs; trebuie s fie
complet n termeni de funcionalitate i performan dar nu ntregul
plan proiectat anterior. Unii denumesc aceasta produs minim viabil - (eu i zic produsul minim iubibil) pentru c depunnd efort
minim, trebuie s creezi o parte din produsul complet pe care att
compania ta, ct i clienii ti, o vor iubi.
3. Implementeaz i testeaz partea aleas pe un set de date demn de
big data. Implementarea e partea cheie, dar testarea e la fel de important deoarece atributele calitii pentru performa au relevan
mai mare cnd discutm de big data (cu accentul pe big). Deci, chiar
dac soluia este performant pe un set de date de test, este inutil
dac pe date de producie nu funcioneaz. De asemenea, ca parte
din faza de testare, este chiar testul n producie, confruntarea cu
utilizatorii, primirea feedback-ului, adevrata evaluare a valorii noului
product. Rezultatele din sistemul live ar trebui s influeneze deciziile
din urmtorii pai.
4. Mergi la pasul 1. Da, este o reet cu bucl, pentru c schimbarea este
continu la un produs, dac vrei s rmi pe pia. Mai mult, prin big
data, formatele de date, sursele, frecvena sunt n continu schimbare
i trebuie meninut pasul; i n acelai timp trebuie mereu ncorporat
feedback-ul de la clieni.
O idee de avut n minte pentru oamenii de afaceri, este ca atunci cnd iau
n considerare big data, mai nti s se asigure c produsul curent sau baza
este n regul i c noua dezvoltare va fi stabil . O alt idee, conform scenariului de mai sus, este s se mite cu pai mruni, iar la fiecare incrementare
s integreze opiniile adevrailor utilizatori.
ELIBERAREA DE SUB PRESIUNE PERSPECTIVA TEHNIC

Trendul big data s-a format mai mult n jurul provocrii tehnice pe care o
expune - este pur si simplu o realitate pentru unele companii, dect o ofert
irezistibil pentru afacere; deci presiunea e mai mare asupra prii tehnice:
87
modul de stocare a datelor, algoritmii, instrumentele, arhitectura aplicaiei

trebuie s se schimbe pentru a mbria i folosi big data. Fiecare dintre aspectele enumerate anterior sunt subiectul a numeroase articole, aadar ideile
urmtoare sunt cel mult un punct de pornire.
Cu riscul de a prea o repetiie, trebuie precizat c nainte de a ncepe
un proiect big data peste o aplicaie existent, clasic, trebuie s ai partea
de small data pus la punct. Dac datele ajung n mod constant ntr-o stare
inconsistent i este necesar intervenie uman n baza de date pentru a le
fixa sau dac n mod constant te izbeti de un zid cnd vine vorba de flag-uri,
statusuri, etc. sau dac tu i echipa ta bjbii prin ntuneric cutnd semnificaia anumitor date, atunci nu mai visa la big data i ai grij de datele existente. Big data, dac nu este ncadrat ntr-o baz stabil, produce dezastre.
Ca persoan tehnic, nu trebuie s te gndeti c noua tehnologie ce vine cu
big data va nlocui vechiul sistem de stocare de date, iar datele tale dezordonate se vor potrivi perfect cu noua abordare. O aplicaie ce folosete big data
nu terge tot ce exist, de fapt este construit s completeze funcionalitatea
i arhitectura curent.
Provocarea big data este s faci gestiunea corect pe ntregul parcurs al
datelor prin aplicaie: modelare, stocare, procesare, utilizare. n jurul tuturor
acestor pai din ciclul de via al datelor, foarte multe instrumente au fost
create pentru managementul lor, ceea ce face s fie o decizie grea alegerea
stivei tehnologice pentru aplicaie; de aceea, tool-urile precizate nu trebuie
luate ca model de bun practic.
MODELARE PENTRU BIG DATA
Unele persoane nc presupun c suportul pentru date nestructurate, fr
schem, ntr-o varietate mare de formate, cruia i se face publicitate constant
pentru a fi implementat de instrumentele pentru big data, este echivalent
cu concedierea tuturor analitilor de date. Dimpotriv, modelarea i analiza
datelor a devenit mai important dect era pentru c o varietate mare de date
trebuie s fie validate de oameni: nu are sens s i aduci date despre psri
dac aplicaia ta e despre aciuni la burs. Mai mult, alimentarea unui tool cu
un morman imens de date, fr nici o indicaie de folosire, ar putea rezulta
n cel mai bun caz, cu instrumentul potrivit, n obinerea abilitii de a cuta
orbete prin toate datele. Ca orice alt instrument computaional, tool-uril
pentru big data au nevoie de informaii pentru a transforma datele n for-
88
mat-main pentru cele mai bune rezultate.

Modelarea de date n contextul big data are nevoie de o alt abordare.
Dac pentru problema clasic, normalizarea era cheia pentru o soluie de
succes, fr a lua n considerare funcionalitatea cerut pentru aplicaie, n big
data, cerinele funcionale preiau conducerea prin utilizarea denormalizrii
personalizate pentru aplicaie. n timp ce normalizarea sparge datele brute
de dragul protocolului, denormalizarea se face doar pentru a servi aplicaia.
Mai mult, procesul de modelare a datelor ce presupune normalizarea este
greu maleabil: odat ce modelul a fost stabilit, n cazul unor probleme de
performan, doar modelul de interogare este ajustat pentru mbuntirea
rezultatelor. ntr-un scenariu asemntor, dar folosind o baz de date denormalizat, procesul este mai agil: att interogrile, ct i modelul sufer
alterri pentru a obine cele mai bune rezultate.
STOCARE PENTRU BIG DATA
O aplicaie modern, n ceea ce privete stocarea de date, nu se mai bazeaz doar pe un sigur sistem de stocare, cum ar fi cel mai faimos: bazele de
date relaionale. De asemenea, cnd adaugi n schem big data nu nseamn
c noul sistem ales pentru depozitarea datelor le va nlocui pe toate celelalte.
Informaii sensibile despre utilizatori (parole, adresa de acas, informaii legate de cardul de credit), detalii despre comenzi (pre, status, informaii livrare), etc., nu ar trebui s fie stocate ntr-un sistem big data deoarece acest tip
de date este menit s rmn sub incidena i managementul bazelor de date
relaionale. Cu alte cuvinte, configurarea pentru stocarea de date trebuie s
fie de tip poliglot. Date sensibile i vitale pentru procesul aplicaiei ar trebui
meninute n bazele de date relaionale, datele ce vin n perechi (valuta i cursul valutar, ar i drapel) ar trebui inute n baze de date cheie-valoare (cum
ar fi Redis), n timp ce datele nestructurate ar trebui stocate n baze de date
NoSQL, alese n funcie de tipul datelor. Dac datele tale sunt similare cu
documentele, atunci ar trebui s alegi o baz de date pentru documente (cum
ar fi Cassandra, MarkLogic, MongoDB, etc.); dac datele tale conin triple,
atunci ar trebui s foloseti o baz de date graf (Neo4j, Titan, AllegroGraph,
etc.).
PROCESAREA BIG DATA
Pentru o perioad destul de lung de timp, s-a remarcat o confuzie general legat de echivalena ntre big data i pasul de procesare pentru big
89
data : task-urile map-reduce implementate n Hadoop erau considerate a fi

cel mai bun mod de a trata big data; ns Hadoop este doar un instrument
din stiva tehnologic ce poate fi folosit pentru aplicaii big data. Totui,
vasta rspndire a instrumentelor de executare de map-reduce a fost o mare
reuit n lumea big data; din cauza volumului n cretere de date, procesarea
a fost mpins ctre o abordare distribuit pentru mai mult eficien - deci
s-ar putea nelege sursa confuziei. De-a lungul timpului, Hadoop a devenit
liderul n ceea ce ine de stocare i procesare offline pentru big data; chiar i
aa, ideea de offline ncepe s se nvecheasc n timp ce alte abordri pentru
map-reduce prind vitez - Spark, Summingbird sunt exemple de tool-uri pentru execuie n timp real de task-uri map-reduce n memorie.
Pasul de procesare nu se aplic doar o singur dat n ciclul de via a datelor; procesarea se poate face la momentul ingestiei, declanat de un eveniment sau bazat pe un program. Scopul procesrii este de a cura datele, de
a extrage informaii relevante, mbogirea datelor cu mai multe informaii.
n relaie cu modelarea, procesarea poate fi un instrument util de folosit:
s presupunem c datele vin dintr-o surs extern (nu din ETL-ul sistemului), iar pentru aplicaie este nevoie de o alt structur, derivat din cea original; n aceast situaie, procesarea la momentul ingestiei, este recomandabil
pentru a avea doar date curate n baza de date. Denormalizarea - oportun
pentru acest context - poate cauza probleme de integritate, care trebuie rezolvate ulterior (n cazul n care master-ul datelor este n sistemul big data).
Aadar un task de procesare poate fi distribuit pentru a restabili consistena.
Procesarea merge mn n mn cu funcionalitatea aplicaiei (la fel ca
modelul), deci, la nceput, pasul de procesare era folosit doar pentru operaii
simple, cum ar fi rapoarte statistice peste seturi prea mari de date pentru a fi
acoperite de instrumentele tradiionale. Cu timpul, procesarea a ajuns s fie
folosit pentru a extrage cunotine dintr-o mas mare de date. De exemplu, entitile numite pot fi extrase pentru a face parte din triple, iar n acest
mod se poate forma un graf de relaii peste datele existente; sau entitile
recunoscute pot fi marcate n documentul original pentru a oferi mai mult
structur i pentru a uura accesul la informaii.
UTILIZAREA BIG DATA
O parte a problemei cu big data este faptul c volumul presupus este att
de mare nct o nou stiv tehnologic trebuie aleas doar pentru a ine n
via procesele mai vechi; ns aceasta este doar tratarea unui simptom nu un
90
mod de a valorifica ceea ce ofer big data. Cu un volum mai mare de date,
chiar i statisticile devin mai semnificative i exacte, iar o corelaie ce pare o
coinciden poate fi demonstrat cu valori - ceea ce aduce mai multe informaii pentru business.
O alt dimensiune pentru big data este varietatea i aceasta ar putea
reprezenta cheia pentru a descoperi informaii valoroase. Diferite surse de
date pot oferi date despre aceeai entitate, deci modele se pot descoperi i
n date neuniforme. Asemenea informaii pot mbunti reinerea de clieni printr-o experien complet personalizat per utilizator, nu doar pentru
publicitate i marketing, ci i pentru modelul afacerii; s luam de exemplu
poliele de asigurare pentru maini, i modul lor de calculare doar n funcie
de nite parametri fici (cum ar fi vrsta). Cum ar fi dac comportamentul
oferilor n trafic ar putea fi accesibil prin senzori sau o aplicaie? Atunci,
poate oferii tineri ar putea avea polie mai ieftine pentru c ar putea dovedi
cu date c sunt oferi siguri, n ciuda vrstei lor, iar businessul ar atrage mai
mult clientela tnr.
n ceea ce privete algoritmi folosii, nu sunt prea multe nouti pentru
big data; algoritmii de nvare automat primesc n sfrit atenia cuvenit.
Odat cu creterea cantitilor de date din aplicaii i cu progresul fcut pe
sursele adnotate ( pentru procesarea limbajului natural - corpusuri adnotate,
tezaure extensive, ontologii), analiza de sentimente, previziunile, clasificarea
automat a clienilor, ies din laboratoarele de cercetare i pot fi folosite pentru a mbunti afacerea. ntr-adevr, n zona tool-urilor o multitudine de
opiuni au aprut (Mahout, OpenNLP, PredictionIO, Jubatus, Encog, etc.)
pentru a ncuraja uzul ct mai general. n plus, pentru rezultate mai bune i
integrarea cu executoarele de map-reduce, algoritmii au fost uor modificai
pentru a funciona i ntr-o abordare distribuit.
De-a lungul descrierii pailor pentru managementul big data, multe baze
de date NoSQL, executoare distribuite de map-reduce i framework-uri dependente de domeniu au fost precizate, multe dintr ele open source, ceea ce
nu ar trebui s impun limite n ceea ce privete costul. ns e chiar aa?
Pentru mine cea mai bun caracterizare pentru software open source este libertatea exprimrii nu nseamn bere gratis, dar nu datorit modelelor de
liceniere (cum se folosete de obicei). Mie mi place s duc analogia ctre
relaia dintre timp i cost pentru construirea unui produs: i-ai putea exersa
91
libertatea exprimrii i eventual vei convinge pe cineva s-i cumpere bere,

dar nu ar fi fost mai rapid s o cumperi? Decizia ce trebuie luat n materie
de tehnologii se refer la : dac ai gsit gratis tool-urile potrivite pentru a
implementa funcionalitatea, dar echipa de dezvoltare trebuie s lucreze la
integrare,dar n acelai timp, exist o alternativ cu licen pltit ce necesit
mai puin efort pentru dezvoltare, atunci ce alegi? Argumentul costului nu
mai este valabil. Partea mai puin bun n a avea o multitudine de tool-uri
la dispoziie este c majoritatea lor nu au timp s se maturizeze, s formeze
comuniti n jurul lor, pentru c altele apar i pretind a fi mai bune; de aici
vine lipsa de standard i de reete despre cum se poate aborda tehnic big data.
PRESIUNE BUSINESS VS. IT

Departamentul de business i cel de IT nu au mereu o relaie prea fericit.
Oamenii de afaceri sunt un fel de vistori la venituri, iar oamenii de IT sunt
interesai doar de codul lor i de tehnologiile pe care le pot experimenta. Unde
se potrivete big data ntre aceste dou pri? Unele persoane cred c datele
intr n responsabilitatea departamentului IT i n acest caz, schimbarea big
data trebuie iniiat de aceast parte. Adevrul este la mijloc, ambele pri
trebuie s se informeze reciproc i continuu despre orice oportunitate de a
mpinge lucrurile nainte, deoarece responsabilitatea este a amndurora. Big
data trebuie s fie recunoscut de oamenii mai puin tehnici, cel puin ca i
coninut i trebuie privit ca orice alt tehnologie: avanseaz afacerea. De-a
lungul prezentrii punctelor cheie pentru big data pentru partea tehnic, s-a
subliniat faptul c n timpul implementrii i a lurii deciziilor tehnice, cerinele funcionale trebuie s conduc. Aadar - fcnd un pas n spate pentru
a avea imaginea de ansamblu - ideea este c business-ul trebuie s aib ceul, iar IT-ul cum-ul.
Un punct dureros n relaia business-IT este c big data nu poate salva o
companie. Dup cum s-a explicat mai devreme despre problemele cu small
data, pot exista i alte probleme de esen cu rdcini vechi, iar unele persoane pot decide naiv c big data va ndeprta toate problemele. Fr a fi
un sfat foarte bun pentru aplicaiile big data, trebuie reinut faptul c nici
o tehnologie nu poate s schimbe modul de gndire al unei companii i s
mpiedice prsirea pieei competitive.
92
N AFARA PRESIUNII BIG DATA

Lund n considerare ultimele seciuni, s-au oferit informaii de baz
pentru a avansa n lumea big data att pentru business ct i pentru IT. Dar
este suficient pentru un plan de lung durat i o supravieuire fr stres?
tire bomb: presiunea nu dispare niciodat! n zilele noastre, nevoile tehnologice dar i cele de afacere, avanseaz ntr-un ritm alert, deci noi surse de
dificulti pot aprea. Indiferent de mediu, este important s lsm partea
funcional s conduc, iar tehnologia i va urma n concordan cu nevoile
specifice. n acelai timp, s fim ateni la balana dintre costul pentru big data
i profit (fie cel curent sau cel pronosticat).
Toi angajaii companiei de poveste au citit acest material plin de informaii importante i oamenii de business au nceput s lucreze mai aproape
de IT, iar nivelul de stres al companiei scdea n timp real. i aa compania a
nceput s lucreze cu big data i au operat fericii pn la adnci btrnei
Autori
Silvia Rusanu - Senior Developer @ ISDC
Dan Danciu - Software Architect @ ISDC
93
Bogdan Rus
Dr. ing. Andrei Bogdan Rus este ef lucrri (lector) n cadrul Universitii Tehnice din Cluj-Napoca, Facultatea de Electronic, Telecomunicaii
i Tehnologia Informaiei. Devenind din anul 2008 membru al colectivului
UC Labs (Unified Communications Laboratories) din cadrul aceleiai faculti, domnul Rus a participat n proiecte de cercetare internaionale ce aveau
ca tem principal tehnici de comunicaii n Internetul viitorului. Rezultatul
ntregii activiti de cercetare a fost validat n diverse articole publicate la
conferine internaionale i reviste de specialitate. Adiional activitilor de
cercetare, Andrei Bogdan Rus este implicat i n activiti didactice cu studenii nscrii la cursurile de licen i masterat.
10
TENDINE DE EVOLUIE A
COMUNICAIILOR SPRE
INTERNETUL VIITORULUI
n ziua de azi, lumea comunicaiilor prin Internet cunoate o efervescen

tot mai crescut, cu un numr din ce n ce mai variat de servicii ce vin n ntmpinarea nevoilor utilizatorilor. n spatele acestor servicii recent aprute se
afl de cele mai multe ori tehnologii noi ce ofer posibilitatea schimbului de
date la viteze din ce n ce mai mari, noi paradigme de accesare a informaiei
i nu n ultimul rnd noi metode de utilizare/partajare a resurselor din infrastructurile de comunicaii existente.
n cadrul acestui context de cristalizare de noi direcii i tehnologii, apare
conceptul de separare a planului de control al rutrii de cel al comutaiei
fluxurilor de date. Dac n abordarea clasic ambele sunt implementate la nivelul echipamentelor de rutare, exist n prezent o tendin clar de transfer a
mecanismelor de control ctre un nivel superior, ct mai aproape de aplicaii.
Aceast abordare este cunoscut n literatura de specialitate sub numele de
SDN (Software-Defined Networking reele definite prin software). Planul
de control din paradigma SDN are acces direct la planul de comutaie a datelor, ce nglobeaz echipamentele din infrastructura de reea (ex. router-e,
switch-uri i alte echipamente intermediare). ntregul efort de schimbarea
a paradigmei reelelor cu comutaie de pachete are ca el final facilitarea
implementrii de soluii inovative care s aduc mbuntiri majore comunicaiilor prin Internet, n cel mai scurt timp. Printre cel mai des ntlnite
aplicaii care au adoptat aceast abordare, putem aminti: controlul dinamic
al accesului utilizatorilor n reea, distribuirea eficient a ncrcrii serverelor,
virtualizarea resurselor reelei, eficientizarea consumului de energie a reelei,
96
migrarea automat a mainilor virtuale fr ntreruperea serviciilor [1].

Primele implementari comerciale de succes ce au adus tehnologia
SDN n lumina reflectoarelor au fost: sistemul de management al traficului
n WAN (Wide Area Network), dezvoltat de Google [2] i platforma de
virtualizare a resurselor din reea dezvoltat de Nicira, companie achiziionat de ctre VMware. n prezent, majoritatea marilor juctori din domeniul
tehnologiei informaiei precum furnizori de servicii de tip cloud, furnizori de
Internet, productori de echipamente i companii de servicii financiare au
format diverse consorii n cadrul crora i concentreaz eforturile n vederea dezvoltrii tehnologiei SDN : Open Networking Foundation [4], Open
Daylight [5]). Astfel, putem afirma faptul c n prezent se fac pai concrei
ctre realizarea unui vis demult enunat i anume crearea reelelor de date
cu adevrat programabile care pot s se adapteze fr probleme la dinamica
serviciilor disponibile i accesate n ziua de azi prin Internet. Din punct de
vedere istoric se evideniaz trei faze ale evoluiei spre ceea ce nseamn n
ziua de azi reele programabile:
1. Din a doua jumtate a anilor `90 i pn la nceputul anilor 2000 a
aprut conceptul de reea activ ce a introdus funcii programabile n
arhitectura reelelor de calculatoare;
2. n perioada 2001 2007 s-a vehiculat ideea separrii planului de
comutaie a datelor de cel de control datorit apariiei de interfee
specializate ce au facilitat comunicaia dintre cele dou;
3. ncepnd cu anul 2007 apare tehnologia OpenFlow mpreun cu diverse versiuni de sisteme de operare deschise, create special pentru
echipamente de reea.

Una dintre aplicaiile tehnologiei SDN considerate a fi cele mai importante la ora actual i pentru dezvoltarea creia se aloc n prezent cele mai
multe resurse, este platforma de virtualizare a resurselor reelei. Aceast faz
este urmtorul pas logic ce este necesar a fi efectuat dup apariia soluiilor
de virtualizare a puterii de calcul i a capacitii de stocare. Un alt factor
important ce accelereaz dezvoltarea acestei direcii este apariia pe pia a
operatorilor virtuali de telecomunicaii. Acetia utilizeaz parial resursele
infrastructurilor de comunicaii a unuia sau mai multor furnizori, pentru a
oferi servicii noi utilizatorilor.
Restul articolului este organizat dup cum urmeaz: capitolul doi demonstreaz c tehnologia OpenFlow este cea mai semnificativ din grupul de
soluii SDN existente la ora actual, urmnd ca n capitolul trei s prezentm
TENDINE DE EVOLUIE A COMUNICAIILOR
97
o aplicaie n care aceasta este folosit cu succes pentru a optimiza rutarea

datelor n interiorul reelei. Capitolul patru conine rezultatele experimentale care confirm avantajele protocolui de rutare propus. Capitolul cinci
ncheie aceast lucrare cu un set de concluzii ce sintetizeaz principalele idei
ce trebuie reinute vizavi de conceptele prezentate.

TEHNOLOGIA OPENFLOW
Mecanismele de tip SDN fac parte dintr-o arhitectur n care componenta de control a reelei este decuplat de cea de comutaie a datelor i adus
mai aproape de stratul aplicaie prin biblioteci de funcii specializate (API
Application Programming Interface). n consecin, se permite optimizarea deciziilor luate n reea astfel nct s se in cont de cerinele serviciilor
a cror date sunt transmise prin infrastructura de comunicaii (vezi Figura
1). Un alt avantaj al acestei abordri este faptul c echipamentele din reea
pot fi mult simplificate deoarece acestea nu mai trebuie s implementeze o
gam foarte larg de protocoale deoarece toate deciziile sunt luate de ctre
entitatea de control a reelei. Singura cerin pentru aceste echipamente este
ca ele s accepte i s execute instruciuni provenite de la entitatea de control.
Astfel, configurarea securizarea i optimizarea infrastructurii se poate face
automat cu programe specializate n executarea acestor funcii.
Prima soluie aprut
ce permite interfaarea
planului de comutaie a
datelor cu cel de control,
n vederea implementrii paradigmei SDN,
este tehnologia OpenFlow. Aceasta permite
accesul direct i controlul echipamentelor de
comutaie existente n
infrastructura de reea:
comutatoare i router-e
[6]. Figura 1. Arhitectura SDN

98
Figura 2. Control la nivel de flux cu ajutorul OpenFlow
n ceea ce privete granularitatea de reprezentare a datelor, se folosete

noiunea de flux ce identific unic date care respect un set predefinit de
reguli. Spre deosebire de rutarea clasic, programarea funcionrii reelei la
nivel de flux de date ofer un control fin ce permite infrastructurii s rspund n timp real la toate schimbrile ce apar datorit dinamicitii aplicaiilor (vezi Figura 2). Cheia acestei abordri este tabela de fluxuri ce conine
informaii referitoare la setul de date ce strbat fiecare echipament n parte
[7]. Pe lng partea de identificare, o astfel de tabel conine i aciunea ce
trebuie luat atunci cnd un pachet recepionat este detectat ca fcnd parte
dintr-un anumit flux de date. Aceast aciune specific de cele mai multe ori
interfaa de ieire pe care trebuie redirectat mai departe pachetul n calea sa
spre destinaie (vezi Figura 3).
Utilizat iniial doar n infrastructuri bazate pe tehnologii din familia
Ethernet, OpenFlow poate fi n ziua de azi implementat att n reele fizice
ce utilizeaz o gama larg de tehnologii ct i n reele virtuale. Deoarece
echipamentele ce suport rutarea bazat pe mecanisme OpenFlow implementeaz i protocoale clasice de rutare, adoptarea acestei tehnologii SDN
de ctre furnizorii de servicii se poate face progresiv, meninnd costurile la
nivele acceptabile.

99
Figura 3. Tabela de fluxuri, existent n echipamente compatibile OpenFlow
Odat cu apariia tehnologiei OpenFlow au fost elaborate o serie de

soluii de control a reelei ce se bazeaz pe aceasta: NOX, Beacon, Helios,
Big Network Controller, SNAC i Maestro. Primul mecanism aprut ce se
ncadreaz n aceast categorie a fost NOX. Acesta este de fapt un sistem
de operare cu rol de control a reelelor ce conin echipamente de comutaie
OpenFlow, oferind suport pentru aplicaii scrise n limbajele C++ i Python. O a doua soluie disponibil pentru control este Beacon. Aceasta are
ca principal caracteristic posibilitatea de a permite extinderea funcionalitii sale prin adugarea de module scrise n limbajul Java. De asemenea, are
la baz framework-ul OSGi (Open Service Gateway initiative) ce permite
aplicaiilor de control s fie pornite, oprite sau reiniializate fr a pierde
conexiunea cu infrastructura controlat. Destinat ndeosebi grupurilor de
cercetare, Helios este o soluie de gestiune a funionalitii reelei elaborat
de ctre NEC n limbajul de programare C. Aceasta ofer un interpretor de
comenzi (en. shell) programabil destinat executrii de experimente automatizate cu un grad ridicat de complexitate. Big Network Controller este un
utilitar proprietar bazat pe Beacon i elaborat de ctre compania BigSwitch.
Acesta ofer o interfa n linie de comand destinat controlului reelei. Bazat pe NOX, soluia SNAC face parte din categoria programelor publicate
sub licen GNU (GNUs Not Unix!). Acesta ofer o interfa intuitiv i
uor de utilizat pentru controlul punctelor de comutaie din reelele de calculatoare folosind limbajul FML (Formal Modelling Language) cu ajutorul
cruia se pot specifica politici de funcionare. Utilitarul Maestro elaborat de
100
ctre Rice University ca entitate de orchestrare a funcionrii reelei, este bazat pe limbajul Java i ofer posibilitatea de extensie a acestuia prin module
adiionale adugate n funcie de necesiti. O alt caracteristic este faptul
c a fost optimizat pentru rularea n paralel a mai multor fire de execuie n
vederea creterii performanelor de control.

Printre beneficiile ce pot fi dobndite n urma utilizrii tehnologiei
OpenFlow am putea enumera [6]:
1. Creterea securitii reelelor prin definirea la nivel nalt a politicilor corespunztoare. Prin intermediul tehnologiei OpenFlow, acestea sunt translatate n instruciuni specifice fiecrui echipament din
reeaua controlat. n cazul n care apar schimbri ale infrastructurii
operaionale, actualizrile se vor executa ntr-un timp mult mai scurt
dect n abordarea clasic. Deoarece tehnica SDN ofer o vizibilitate
global asupra reelei, se asigur faptul c setrile de control acces,
inginerie a traficului i calitate a serviciilor sunt implementate unitar
n ntreaga infrastructur, inclusiv campusuri, centre de date, filiale
distante.
2. Controlul centralizat al unei infrastructuri de reea multi-vendor n
vederea punerii n funciune i a configurrii ct mai rapide a acesteia.
3. Controlul bazat pe flux permite o gestiune granular a ntregii reele
astfel nct se pot specifica politici la nivel de utilizator, echipament
sau aplicaie. Acest fapt permite furnizorilor de servicii cloud s ofere
suport pentru izolarea traficului, securitate i management elastic al
resurselor n scenarii n care mai muli utilizatori partajeaz aceeai
infrastructur.
4. Creterea satisfaciei utilizatorilor. Acest beneficiu este datorat faptului c parametrii ce reflect n timp real proprietile reelei sunt pui
la dispoziia aplicaiilor de nivel nalt, astfel nct deciziile acestora s
fie optimizate la situaia actual. Un exemplu concludent n acest sens
ar putea fi eficientizarea serviciilor de tip IPTV (Internet Protocol
Television) care transmit fluxuri video n timp real. Cunoscnd starea
reelei i rata de transfer disponibil, acestea pot modifica dinamic
rata la care se face compresia fluxului astfel nct s adapteze automat
cantitatea de date transmise pe canal.
5. Accelerarea inovaiei prin implementarea unor noi modele de business. De exemplu, oferirea de servicii de tipul IT-as-a Service n
care este necesar posibilitatea modificrii dinamice a modului de
101
funcionare a infrastructurii astfel nct s fie ndeplinite nevoile aplicaiilor i ale utilizatorilor.
6. Reducerea complexitii de operare prin automatizarea proceselor de
management a reelei. Astfel, se pot minimiza costurile operaionale
i se pot elimina perioadele de instabilitate aprute datorit erorilor
inserate de ctre factorul uman.
Mecanismele de tip SDN i n consecin tehnologia OpenFlow apare ca rspuns la tendinele de virtualizare a resurselor de calcul, dorina de
mbuntire a mecanismelor de mobilitate i apariia soluiilor de tip ITas-a-Service (infrastructur IT ce este utilizat doar la nevoie), care exercit
o presiune semnificativ, creia reeaua clasic nu i poate face fa. Astfel,
este nevoie ca aceasta s se poat adapta n timp real la cerinele dinamice
provenite din partea utilizatorilor, devenind astfel o platform optimizat
pentru livrarea eficient a unei game variate de servicii.
OPTIMIZAREA RUTARII UTILIZND

COMUTAIA DE ALGORITMI
Nu putem vorbi de o reea dinamic ce are capacitatea de a se adapta la
necesitiile utilizatorilor i a serviciilor transportate, fr s abordm diverse
aspecte de eficientizare a rutrii. n consecin, n acest capitol vom prezenta
o soluie ce i propune s ofere posibilitatea de implementare a mecanismelor dinamice de rutare.
Paradigma dup care a evoluat lumea reelelor de calculatoare de-a lungul
timpului presupunea elaborarea a cte unui protocol distinct pentru rezolvarea fiecrei probleme de comunicaii. Se poate nelege astfel motivul pentru
care n ziua de azi exista o gam larg de protocoale ce trebuie activate pe
echipamentele din infrastructura reelei n vederea implementrii unui anumit set de politici. n ceea ce privete rutarea, exist protocoale de rutare dedicate fiecrui scenariu ce poate fi ntlnit: protocoale de tip vector distan,
protocoale bazate pe starea legturii, protocoale intradomeniu i protocoale
ce se ocup cu rutarea datelor ntre domenii autonome diferite. Fiecare dintre acestea folosec un anumit algoritm pentru luarea deciziilor de rutare (vezi
Figura 4). nelegerea i utilizarea tutoror acestor soluii a devenit o sarcina
dificil pentru administratorii reelelor, crescnd astfel costurile operaionale
102
pentru astfel de infrastructuri.
Figura 4. Relaia dintre protocoalele de rutare i algoritmi n abordarea clasic
n ntmpinarea acestei probleme, propunem unificarea tuturor protocoalelor de rutare ntr-unul singur ce poate fi utilizat n toate scenariile posibile.
Acesta este capabil s i adapteze comportamentul n funcie de cerinele
fiecrui flux de date n parte. Cu alte cuvinte, deciziile de rutare nu mai sunt
luate de ctre un singur algoritm, indiferent de necesitiile curente. GRAS
(Gearbox-like Routing Algorithms Selection) [8] este soluia propus a fi
rspunsul la problema enunat anterior i presupune punerea la dispoziia
protocolului de rutare a unui set de mai muli algoritmi, din care va fi activat
la un moment dat cel mai potrivit pentru scenariul n cauz (vezi Figura 5).
Figura 5. Ilustrarea conceptului GRAS
103
Algoritmii prevzui a fi utilizai ntr-un astfel de sistem adaptiv sunt

urmtorii (setul poate fi extins n funcie de necesiti cu efort minim, deoarece modificrile ce trebuie aduse vor fi implementate doar pe elementul de
control centralizat a reelei cu capabiliti OpenFlow):
a. Floyd-Warshall [9]: utilizat pentru gsirea cii optime ntre toate
perechile de noduri surs-destinaie dintr-o topologie oarecare. Acest
algoritm este recomandat a fi utilizat de ctre operatorii de infrastructur de telecomunicaii pentru a oferi tuturor abonailor cea mai bun
cale spre destinaie.
b. Dijkstra modificat [10]: este optimizat pentru gsirea cii optime
dintre un nod surs i mai multe noduri destinaie ntr-o infrastructur dat. Acest model de comunicaie este recomandat n scenariile
n care se dorete gsirea cilor optime de la un furnizor de servicii
(transmisii video la cerere, televiziune prin Internet, furnizor de servicii cloud etc.) ctre clienii acestuia.
c. Ford-Fulkerson [11]: acest algoritm poate fi folosit cu succes n cazul
n care ruta optim dintre un nod surs i un nod destinaie nu are
capacitatea de a suporta rata de transfer a datelor ce trebuie transmise
ntre cele dou noduri. n consecin, este necesar utilizarea acestui
algoritm de rutare pe ci multiple pentru a gsi toate traseele disponibile ntre surs i destinaie.
n funcie de starea reelei i a cerinelor de performan provenite din
partea utilizatorilor i a serviciilor transportate, se va alege algoritmul optim
din lista de mai sus. Deoarece infrastructura de comunicaii are proprieti
dinamice n timp, este nevoie ca msurtori specializate s se efectueze n
timp real astfel nct deciziile luate s fie n concordan cu starea actual.

REZULTATE EXPERIMENTALE
Pentru a ilustra fezabilitatea ideilor enunate n capitolul anterior s-a

utilizat o topologie de test format din patru echipamente pe care ruleaz
soluia Open vSwitch 1.3 (acesta este un switch virtual ce implementeaz
tehnologia OpenFlow). Managementul n timp real al reelei s-a fcut de pe
un calculator adiional pe care ruleaz soluia Beacon (prezentat n capitolul
2) i utiliznd o infrastructur de reea dedicat schimbului de date de control. Traficul util trimis prin reeaua de test a fost transmis ntre o staie cu
104
rol de surs i una cu rol de destinaie (vezi Figura 6).
Figura 6. Topologia de test utilizat
Nodurile SW1, SW2, SW3 i SW4 sunt configurate s efectueze comutaia astfel: de fiecare dat cnd un pachet este recepionat, se ncearc
determinarea fluxului din care face parte. Dac o aciune a fost definit vizavi
de fluxul n cauz, aceasta va fi executat (pachetul va fi transmis pe portul
de ieire corespunztor, determinat cu ajutorul algoritmului de rutare activat
pentru situaia respectiv), n caz contrar, pachetul este ncapsulat i trimis
mai departe ctre entitatea de control (Beacon). Dup procesarea acestei informaii se va trimite ctre nodul de comutaie aciunea ce trebuie aplicat
pentru urmtoarele pachete primite, ce fac parte din acest nou flux.
Scenariul de test implementat presupune transmisia ntre nodurile Surs
i Destinaie a ase fluxuri (F1, F2, .. , F6) a cte 30 Mbps fiecare, ctre nodul
Destinaie. Acestea au fost pornite la un interval de 20 secunde unul de cellalt. Marcm momentele de timp astfel: T1, T2=T1+20s, , T6=T5+20s.
n acest scenariu s-a decis utilizarea algoritmului Dijkstra modificat pentru
identificarea celei mai bune ci ntre surs i destinaie. Deoarece numrul
de fluxuri crete n fiecare pas, se observ faptul c din pasul 3 elementul de
control decide folosirea algoritmului Ford-Fulkerson pentru utilizarea n pa-
105
ralel a mai multor ci de transmisie a datelor. Rezultatul cu privire la alocarea

fiecrui flux pe rutele existente, poate fi vizualizat in Tabelul 1.
Ruta
T1
T2
T3
T4
T5
T6
1-2-4
F3
F3
F3, F5
F3, F5
1-3-4
F4
F4
F4, F6
1-4
F1
F1, F2
F1, F2
F1, F2
F1, F2
F1, F2
Tabel 1. Alocarea fluxurilor de date pe fiecare rut
Figura 7. Testul 1: ATR i OWD
n Figura 7 sunt ilustrate graficele ATR (Available Transfer Rate rata de

transfer disponibila pe o anumit rut) i OWD (One-Way Delay latena
msurat pe o rut) pentru cele trei ci existente n topologia de test. Se
observ faptul c de la un moment la altul starea reelei se modific datorit
106
apariiei de noi fluxuri de date trimise ctre destinaie. Utiliznd algoritmul

Ford-Fulkerson se evit astfel utilizarea excesiv a unei singure legturi din
reea (fenomen ntlnit la protocoalele de rutare clasice). Traficul este alocat
dinamic pe toate cile disponibile din infrastructur, reuindu-se astfel ntrzierea momentului de apariie a fenomenului de congestie.
Figura 8. Funcia CDF pentru valorile OWD pe cele trei rute
Rezultatele ilustrate n Figura 8 demonstreaz faptul c implementndu-se un comportament adaptiv al reelei la situaia actual se pot menine
parametri de calitate ai serviciilor (latena) la un nivel mulumitor chiar i n
cazul n care reeaua ncepe s fie utilizat pn aproape de capacitatea maxim. n consecin, acest aspect se va reflecta prin pstrarea unui grad ridicat
de satisfacie a utilizatorilor infrastructurii de comunicaii.
107
CONCLUZII
Evoluia ctre o lume a reelelor programabile, capabile s se adapteze n

timp real la schimbrile ce pot aprea, nu se poate face fr separarea planului
de control de cel al comutaiei. O soluie viabil n acest sens este OpenFlow,
care reuete s abstractizeze funcionarea reelei la un nivel la care o aplicaie poate prelua controlul acesteia. n consecin, comportamentul reelei
va fi optimizat la cerinele existente indiferent de dinamicitatea acestora.
Scenariile ce pot beneficia de pe urma capabilitii unei infrastructuri de
a fi programabil, sunt nenumrate. Printre cele de importan ridicat se
numr aplicaiile de optimizare a rutrii n funcie de necesitile reale ale
utilizatorilor i ale serviciilor utilizate de ctre acetia. n acest articol am
demonstrat faptul c utiliznd un protocol de rutare ce folosete adaptiv, n
funcie de situaia dat, un anumit algoritm de calcul a cilor optime, putem
eficientiza modul de utilizare a resurselor, pstrnd astfel un grad ridicat de
satisfacie. Astfel de abordri vor putea fi testate i mai apoi implementate
n reelele de producie din viitor ntr-un timp relativ scurt, de ndat ce tehnologiile SDN vor fi adoptate la scar larg.
REFERINE BIBLIOGRAFICE
1. [1] N. Feamster, J. Rexford, E. Zegura, The Road to SDN: An Intellectual History of Programmable Networks, ACM SIGCOMM Computer Communications
Review, Aprilie 2014.
2. [2] S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh,
3. S. Venkata, J. Wanderer, J. Zhou, M. Zhu, J. Zolla, U. Hlzle, S. Stuart, and A.
Vahdat. B4: Experience with a globally deployed software defined WAN, ACM
SIGCOMM, Aug. 2013.
4. [3] ***, Its time to virtualize the network, Nicira Whitepaper 2012, http://nicira.
com/en/network-virtualization-platform
5. [4] ***, Open Networking Foundation, www.opennetworking.org
6. [5] ***, Open Daylight, http://www.opendaylight.org/
7. [6] ***, Software-Defined Networking: The New Norm for Networks, Open Networking Foundation ONF White Paper, April 13 2012
8. [7] N. McKeown, et al., OpenFlow: enabling innovation in campus networks,
ACM SIGCOMM Computer Communication Review, 38 (2), April 2008, 69-74
9. [8] A.B. Rus and V. Dobrota, Case Study of a Gearbox-Like Routing Algorithm
Selection in Runtime, 18th IEEE LANMAN 2011, Chapel Hill, North Carolina,
pp. 1-6, DOI: 10.1109/LANMAN.2011.6076938
10. [9] A.G. Furculita, M.V. Ulinic, A.B. Rus, and V. Dobrota, Implementation Is-
108
sues for Modified Dijkstras and Floyd- Warshall Algorithms in OpenFlow,

12th RoEduNet International Conference, Constanta, Romania, 2013, pp.50-55,
DOI:10.1109/RoEduNet.2013.6714208
11. [10] A.B. Rus, V. Dobrota, A. Vedinas, G. Boanea, and M. Barabas, Modified
Dijkstras algorithm with cross-layer QoS, ACTA TECHNICA NAPOCENSIS,
Electronics and Telecommunications, vol. 51, no.3, 2010, pp. 75-80.
12. [11] P. Sevastian, A.B. Rus & V. Dobrota, Simulation of the Ford-Fulkerson Algorithm Using OMNET++, ACTA TECHNICA NAPOCENSIS, Electronics and
Telecommunications, ISSN 1221-6542, Vol.53, No.2, 2012, pp. 23-29
Autori
Dr. ing. Bogdan Rus - ef lucrri @ Facultatea de Electronica,
Telecomunicatii si Tehnologia Informatiei, Universitatea Tehnic
din Cluj-Napoca
Dr. ing Virgil Dobrota - Profesor @ Facultatea de Electronica,
Telecomunicatii si Tehnologia Informatiei, Universitatea Tehnic
din Cluj-Napoca
109
Zsolt Alfrd Polgr
Zsolt Alfrd Polgr a obinut diploma de Inginer cu specializarea Telecomunicaii, Master n Tehnici Avansate n Telecomunicaii i Doctor n
Inginerie Electronic i Telecomunicaii de la Universitatea Tehnic din
Cluj-Napoca n 1995, 1996, respectiv n 2002. Din 1996 este angajat la Departamentul de Comunicaii al Universitatii Tehnice din Cluj-Napoca, unde
n prezent este confereniar. Domeniile de cercetare de interes implic tehnici de codare a canalului, tehnici de codare a reelelor de date, reele radio,
tehnici de comunicaii prin cooperare, arhitecturi avansate de reele de comunicaii. El a fcut parte din grupurile de cercetare ale programelor COST
289 i COST 2100, a fost membru al echipelor de cercetare ale proiectelor
FP7 4WARD i FP7 CODIV i a fost coordonator local al proiectului FP7
UCONNECT.
11
PLATFORMA DE CONECTIVITATE
PERMANENT PENTRU
TRANSPORTUL PUBLIC INTELIGENT
Asigurarea conectivitii permanente pentru vehiculele de transport n

comun i pentru pasagerii acestora este un obiectiv important n contextul
dezvoltrii sistemelor de transport inteligente, a tehnologiilor de comunicaii
ale Viitorului Internet i a oraelor inteligente. O soluie de conectivitate eficient i uor implementabil se bazeaz pe o arhitectur construit peste reele radio multi-tehnologie i multi-operator. Soluia dezvoltat i prezentat aici exploateaz resursele de transmisie oferite de reelele radio eterogene
fr a utiliza informaiile de stare disponibile n reelele de transport ale operatorilor. Proiectarea arhitecturii se realizeaz pe trei nivele distincte i anume: sistem, funcional i platform. De asemenea, sunt stabilite principiile
de proiectare ale mecanismelor necesare pentru funcionarea sistemului de
conectivitate.
IDEEA DE BAZ
Conceptul de Ora Inteligent primete atenie din ce n ce mai mare att
din partea comunitii de cercetare, a administraiei publice ct i a industriei.
Unul dintre aspectele eseniale pentru realizarea unui ora inteligent este
transportul public, care permite oamenilor i lucrurilor s se mite i care este
unul dintre factorii cheie care influeneaz eficiena global a unui ora. Sectorul de transport poate fi mbuntit semnificativ prin utilizarea tehnologiilor informaiei i comunicaiilor, n prezent avnd loc mai multe iniiative n
acest sens. Aceste mbuntiri privesc att serviciile de transport n sine ct
i serviciile oferite pasagerilor, iar o condiie necesar pentru a pune n aplicare aceste servicii este oferirea conectivitii permanente n mobilitate [1].
112
Utilizarea reelelor publice mobile (3G/4G) pentru asigurarea serviciilor de comunicaii pentru aplicaiile specifice Oraului Inteligent nu este
totdeauna soluia cea mai bun. Capacitile de transmisie ale acestor tehnologii pot fi insuficiente pentru volumul de informaii care este n cretere
continu i care trebuie s fie transmis n anumite condiii de fiabilitate i
disponibilitate impuse. Acest lucru este valabil mai ales n situaia de fa,
cnd conexiunea la Internet trebuie s fie furnizat pentru pasagerii unui
autobuz (30 - 40 utilizatori) i pentru alte terminale care necesit rate de bit
relativ mari (ex. camere de supraveghere, afiaje de informare, etc.).
O soluie alternativ la problema n discuie este oferit de dezvoltarea
reelelor de nou generaie (Next generation Networks - NGN), capabile s
foloseasc mai multe tehnologii de transmisie ntr-un mediu multi-operator
i s asigure mobilitate generalizat. Reelele eterogene pot oferi conectivitate fiabil i permanent, satisfcnd i cerinele serviciilor de comunicaii
caracteristice Oraelor Inteligente i Sistemelor de Transport Inteligente [1].
PROIECTAREA ARHITECTURII
PLATFORMEI DE CONECTIVITATE
Proiectarea arhitecturii platformei de conectivitate poate fi realizat n
mai multe etape plecnd de la arhitectura de sistem prezentat n figura 1.
Arhitectura de sistem include patru entiti de baz : Router-ul Mobil Inteligent (Smart Mobile Router - SMR), instalat n autobuz, Gateway-ul (Service Continuity Gateway - SCG), Serverul de Suport (Ubiquitous Continuity
Support Server - UCSS) i o baz de date central (Central Database - CD)
care stocheaz informaiile de stare ale reelei eterogene (Network State Information - NSI). Entitile SCG, UCSS i CD formeaz o Platform Server de Aplicaie (Application Server Platform - ASP), practic o platform
centralizat de suport pentru realizarea conectivitii permanente. ASP are
rolul de a aduna, procesa i stoca ntr-o baz de date central NSI achiziionat de la rutele SMR. Aceast baze de date poate fi utilizat pentru a
optimiza decizia router-elor SMR n selecia reelelor utilizate pentru transmisie.
SMR este echipat cu unul sau mai multe interfee de reea (radio i prin
cablu), care permit conectarea terminalelor pasagerilor (smartphone-uri, laptop-uri, etc.), precum i a diferitelor terminale ale vehiculului (senzori, com-
PLATFORMA DE CONECTIVITATE PERMANENT
113
puter de bord, camer de supraveghere, etc.). SMR este echipat de asemenea

cu mai multe interfee celulare (3G/4G), i interfee WLAN/WiFi folosite
pentru a stabili conexiuni cu reelele publice asigurnd conectivitatea la Internet a terminalelor din autobuz.
SCG asigur continuitatea serviciului, atunci cnd traficul de date este
rutat de la o conexiune wireless la alta. Soluia de conectivitate propus se bazeaz pe cuplarea deschis (open-coupling) a reelelor wireless, adic aceste
reele nu schimb informaii de stare i de management. Router-ele SMR
i SCG comunic prin tuneluri virtuale stabilite n reeaua radio eterogen
(vezi Figura 2). Aceast abordare permite o implementare rapid i eficient
a soluiei, asigurnd independena fa de operatorii de reea. Pe de alt parte, router-ele SMR nu au acces la NSI disponibil n reelele de transport ale
operatorilor i trebuie s realizeze msurarea parametrilor reelei eterogene.
Datele de semnalizare i de msurtori active sunt transmise prin canalele de
date, ceea ce scade eficiena sistemului.
Figura 1. Arhitectura de sistem a platformei de conectivitate
114
Figura 2. Soluia de conectivitate permanent. Arhitectura funcional a sistemului
A doua etap n proiectarea arhitecturii const n analiza funcional a

operaiunilor efectuate de ctre SMR obinndu-se arhitectura funcional
aa cum este prezentat n Figura 2. Subsistemele arhitecturii funcionale a
SMR pot fi organizate n urmtoarele categorii: decizie, execuie, monitorizare, comunicare i configurare. Fiecare dintre aceste subsisteme include
una sau mai multe module funcionale i sub-module. Modulul de decizie
este reprezentat de Subsistemul de Selecie a Reelei i Decizie de Handover Vertical (Vertical Handover - VHO). Acest subsistem decide momentul
iniierii procesului de handover i selecteaz reeaua int pe baza informaiei de stare a reelei obinut de la Subsistemul de Monitorizare. Entitatea
de execuie este reprezentat de Subsistemul de Control al Conexiunii, care
creeaz i controleaz tunelurile IP stabilite peste reelele disponibile i efectueaz operaiunile de handover pe baza deciziilor primite de la Subsistemul
de Decizie. Subsistemul include mai multe sub-module cum ar fi Tabelul de
rutare, modulul de control NAT (Network Address Translation), ncapsulare-Decapsulare. Modulul de monitorizare este reprezentat de Subsistemul
de Monitorizare i Msurare, care include toate sub-modulele pentru achiziionarea informaiilor de stare a reelelor, a informaiilor legate de trafic
i stocarea acestora ntr-o baz de date local, parte a Subsistemului de
Monitorizare. Modulul de interoperabilitate este reprezentat de Subsistemul
de Interoperabilitate care asigur transmiterea mesajelor ntre subsistemele
locale i cele distante. Acest subsistem, care acioneaz ca un comutator de
mesaje, permite modularizarea arhitecturii SMR i o integrare uoar a subsistemelor care efectueaz diferite operaiuni. Subsistemul de Configurare
permite configurarea interfeelor radio, precizarea politicilor de control ale
operaiunilor de handover i stabilirea cerinelor QoS ale serviciilor oferite
115
pasagerilor.
Arhitectura funcional a SCG este similar cu cea a arhitecturii SMRlui, principala diferen constnd n lipsa subsistemului de decizie. Nicio decizie nu este luat de ctre SCG n ceea ce privete operaiunile de handover,
iar Subsistemul de Monitorizare a reelei are o structur simplificat, acesta
oferind doar un sprijin pentru SMR n efectuarea msurtorilor active.
Arhitectura funcional a UCSS este mai simpl i include Subsistemul
de Management al NSI. Aceast entitate ofer suport pentru SMR n luarea
deciziilor de handover. Este important de menionat c deciziile de handover
pot fi luate i fr intervenia UCSS, doar pe baza msurtorilor locale.
A treia etap de proiectare a platformei const n asocierea entitilor
arhitecturii funcionale cu arhitectura platformei hardware utilizate. SMR
a fost implementat pe un microcalculator care are performanele necesare
pentru efectuarea operaiunilor solicitate de sistemul de conectivitate. Figura
3 prezint arhitectura platformei hardware care este echipat cu mai multe
interfee radio 3G/4G i WiFi. Platforma este echipat i cu o unitate GPS
care permite poziionarea SMR n aria de acoperire a reelei eterogene. Sistemul de operare care ruleaz pe microcalculator este un sistem de operare
Linux minimal, ce include numai bibliotecile necesare pentru operaiunile
efectuate de ctre SMR. Figura 3 prezint de asemenea detalii despre comunicaia dintre modulele arhitecturii funcionale a SMR.
Figura 3. Arhitectura platformei hardware i maparea modulelor funcionale
116
PRINCIPII DE PROIECTARE I IMPLEMENTARE

A MECANISMELOR
Asigurarea conectivitii permanente n reele eterogene multi-operator
i multi-tehnologie necesit o serie de mecanisme specifice, care trebuie s
ndeplineasc i anumite cerine de flexibilitate i adaptabilitate la schimbrile parametrilor reelei eterogene.
MECANISMUL DE INTEROPERABILITATE
Acest mecanism, parte a Subsistemului de Interoperabilitate, permite
schimbul flexibil de mesaje ntre procesele care colaboreaz pentru asigurarea conectivitii omniprezente transmind mai departe att mesajele destinate proceselor locale ct i a celor distante. Procesele locale sau distante, care
schimb mesaje trebuie s fie conectate la un Modul de Interoperabilitate local, respectiv la unul similar care ruleaz pe dispozitivul distant. Mecanismul
de interoperabilitate permite exploatarea deplin a caracterului modular al
arhitecturii platformei, fiind posibil nlocuirea sau actualizarea mecanismelor i a algoritmilor, fr a fi necesar schimbarea mecanismelor care interacioneaz cu cele n curs de actualizare. Fiecare modul software care comunic
cu alte module trebuie s aib un ID unic n cadrul platformei.
Dup ce un modul software se conecteaz la modulul de interoperabilitate, prima operaie efectuat este de a trimite ID-ul su unic. Din acel
moment, orice alt proces poate schimba mesaje cu cea actual. Mesajele
schimbate ntre procesele trebuie s aib urmtorul format: <dest IP>,<ID
dest>,<src IP>,<src ID>,<Mesaj>
MECANISMUL DE ACHIZIIE
A INFORMAIEI DE STARE A REELEI
Acest mecanism, parte a Subsistemului de Monitorizare i Msurare,
achiziioneaz parametrii de stare ai reelei eterogene prin efectuarea unor
operaii de monitorizare pasiv i prin msurtori active. Informaia de stare
achiziionat este procesat i apoi stocat ntr-o baz de date local. Subsistemul de monitorizare are o structur modular, un modul separat fiind
dedicat fiecrui tip de interfa radio (WiFi, 3G/HSPA, 4G/LTE, WiMAX,
etc.). n acest fel extinderea platformei cu interfee de reea pentru noi teh-
117
nologii de acces se poate face uor i fr s fie afectat monitorizarea tehnologiilor de acces deja integrate n platform.
Informaiile de stare sunt grupate n trei categorii principale: parametrii
legturii radio (ex. puterea semnalului, SINR, etc.), parametrii de trafic (ex.
numrul de pachete primite/transmise, clasa de trafic, debitul instantaneu
sau cel mediu, etc.) i parametrii de reea (ex. tipul reelei, clasa de serviciu,
numele operatorului, etc.). Aceast clasificare a parametrilor reelei permite
o procesare mai flexibil n condiiile n care se integreaz n platform noi
tehnologii de acces radio.
Mecanismul de monitorizarea parametrilor reelelor WiFi se bazeaz n
special pe funciile oferite de instrumentele integrate n sistemul de operare
Linux (iw tools), care ruleaz pe platforma de conectivitate. Sistemul de operare Linux ofer, de asemenea, un sistem de fiiere virtual, /proc/net/wireless,
care stocheaz mai muli parametri ai conexiunilor WiFi active. Folosirea
unor seturi specific de funcii oferite de programe Daemon (ex.WPA supplicant), reprezint o alt alternativ pentru monitorizarea WiFi.
Mecanismul de monitorizare a interfeelor de reea celular poate fi implementat prin utilizarea comenzilor AT specifice interfeei sau a unor protocoale de interfaare a echipamentelor modem cu terminalele de date, cum
este protocolul QMI (Qualcomm Station Mobile Modem Interface).
MECANISMUL DE MONITORIZARE I
ANALIZ A TRAFICULUI
Mecanismul este parte a Subsistemului de Monitorizare i Msurare, i
are rolul de a identifica fluxurile de date care tranziteaz router-ul SMR precum i de a msura parametrii acestor fluxuri. Informaiile generate de acest
mecanism sunt utilizate pentru implementarea unor operaii de handover i
agregare de band mai complexe i mai eficiente. Principalele operaii efectuate de acest mecanism sunt:
Identificare flux: un flux aplicaie este clasificat pe baza antetului IP
al pachetelor care ajung la SMR, antet care include cicni cmpuri:
adresa IP surs i destinaie, identificatorul protocolului de transport,
portul surs i destinaie.
Monitorizare trafic n timp real: fiecare flux este mprit n dou
fluxuri simplex i numrul de pachete/octei trimii n fiecare direcie
este contorizat fiind calculat periodic debitul instantaneu i cel mediu.
118
Selecia fluxurilor: majoritatea fluxurilor care traverseaz router-ul

SMR sunt de scurt durat (ex. trafic web, interogri DNS, cererile
ARP, etc.). Deoarece metoda de identificare a fluxurilor este precis,
numrul fluxurilor detectate crete foarte rapid i este foarte dinamic. Dei este posibil utilizarea n procesul de decizie a statisticilor
colectate de la toate fluxurile detectate, este mai practic s fie luate
n considerare numai fluxurile relevante, adic cele care au o durat
minim i un debit mai mare dect un prag minim impus. Fluxurile
scurte n rafal sunt grupate ntr-un flux unic care este gestionat ca i
oricare flux relevant. n acest fel complexitatea proceselor de decizie
i execuie handover este pstrat la un nivel acceptabil.
MECANISMUL DE DECIZIE
Arhitectura modular a platformei permite integrarea mecanismelor de
decizie cu complexitate i performane diferite. n funcie de puterea de procesare i memoria instalat a platformei hardware se pot implementa mecanisme de decizie cu complexitate redus care realizeaz o simpl operaie
VHO sau mecanisme de decizie cu complexitate mare capabile de agregarea
lrgimii de band disponibil ntr-o reea eterogen. Pentru a realiza aceast
flexibilitate mecanismele de decizie trebuie s fie separate de cele de monitorizare i cele de rutare. Mecanismul de decizie trebuie s lucreze pe baza unui
numr limitat de parametri de reea i de trafic stocai n baza de date local a
SMR-ului de ctre mecanismele de monitorizare. Parametrii utilizai trebuie
s fie atent selecionai pentru a fi posibil luarea unor decizii rapide i ct
mai apropiate de cea optimal. Drept consecin, schimbarea interfeelor
radio sau ale API-urilor care permit accesul la aceste interfee nu are nici un
efect asupra procesului de decizie. Pe de alt parte schimbarea mecanismului
de decizie nu necesit modificarea mecanismelor de monitorizare i de rutare. Mecanismul de decizie este unul bazat pe evenimente, ceea ce nseamn
c acesta reacioneaz la evenimente sesizate de mecanismele de monitorizare a reelei i a traficului sau la evenimente legate de expirarea unor temporizatoare, ceea ce reduce puterea de procesare necesar. Comenzile generate de
procesul de decizie stabilesc pentru fiecare flux de date identificat care este
reeaua operatorului care trebuie folosit pentru transmiterea acestui flux i
aceste comenzi sunt trimise mecanismului de control al conexiunii, care efectueaz operaiile de rutare necesare.
119
MECANISMUL DE CONTROL AL CONEXIUNII

n funcie de complexitatea procesului de decizie i de cuplajul dintre
reelele operatorilor pot fi utilizate diferite mecanisme de management al
mobilitii i control al conexiunii, cum ar fi mecanismul Mobile IP, mecanisme bazate pe protocolul SIP sau mecanisme bazate pe instrumentele iproute.
O soluie alternativ, integrat n arhitectura platformei i testat n condiii
reale, este reprezentat de utilizarea tuneluri virtuale VPN (Virtual Private
Networks) create ntre fiecare router SMR i gateway-ul SCG, peste toate
reelele de acces radio disponibile. Acest mecanism ruteaz fluxurile de date
pe tuneluri pe baza comenzilor primite de la mecanismul de decizie. Tunelurile virtuale sunt create cu ajutorul software-ului OpenVPN, iar rutarea peste
aceste tuneluri este implementat prin utilizarea mai multor tabele de rutare
virtuale, unul pentru fiecare conexiune disponibil. Pentru a ruta fluxurile de
date pe diferite tuneluri se precizeaz care tabel de rutare virtual trebuie
utilizat pentru fiecare flux n parte. Aceast operaie se poate realiza cu instrumentele disponibile n biblioteca de funcii iptables integrate n sistemul
de operare Linux. Cu ajutorul acestor instrumente se poate ataa un marcaj
pentru orice pachet care are un set specific de proprieti (ex. adres IP surs
i destinaie, port surs i destinaie i protocol de transport utilizat). ntregul
proces trebuie s fie efectuate att pe SMR i SCG, astfel nct setrile s fie
consistente pe ambele dispozitive.
EVALUAREA ARHITECTURII PLATFORMEI I A

MECANISMELOR DE CONECTIVITATE
Conceptele i principiile de arhitectur precum i principiile de proiectare ale mecanismelor de conectivitate expuse au fost utilizate pentru implementarea unei platforme de conectivitate n cadrul proiectului de cercetare
FP7-UCONNECT, finanat de Comisia European. Aceast platform a
fost testat n medii de transmisie eterogene compuse din reele WiFi i
celulare 3G/HSPA att n condiii de mobilitate redus ct i n condiii
de mobilitate vehicular. Rezultatele acestor teste au validat pe deplin conceptele de arhitectur ct i proiectarea i implementarea mecanismelor de
conectivitate. Rezultatele testelor au fost raportate n mai multe publicaii
tiinifice [2] [3] [4] [5] i rapoartele interne ale proiectului FP7-UCONNECT.
120
CONCLUZII
n contextul oferirii de conectivitate radio vehiculelor, au fost dezvoltate
i standardizate diferite sisteme de comunicaii radio. Un astfel de exemplu
este sistemul CALM [6] dezvoltat pentru Sisteme de Transport Inteligente.
Arhitectura sistemului este conceput pe baza funcionalitilor oferite de
stiva de protocoale TCP/IP i ofer conectivitate multi-tehnologie, dar nu
definete mecanismul de execuie al procesului de handover vertical. n acest
caz procesul VHO se realizeaz prin protocolul Mobile IPv6 i, prin urmare,
este nevoie de un grad ridicat de interoperabilitate a reelelor. n comparaie
sistemul CALM arhitectura prezentat n aceast lucrare integreaz mecanismele de decizie i de execuie VHO, ceea ce permite oferirea de conectivitate att n reelele IPv4 ct i IPv6 fr a utiliza funcionaliti oferite de
operatori. Sistemul prezentat permite de asemenea i funcionaliti suplimentare, cum ar fi agregarea de band de la mai multe tehnologii de acces
fr fir, ceea ce asigur conectivitate la Internet chiar i n zonele cu acoperire
slab sau n reele suprancrcate.
REFERINE
1. [1] UCONNECT FP7 project website, http://idi.gowex.com/uconnect/index.

html
2. [2] Z. A. Polgar, A. B. Rus, Z. I. Kiss, A. Consoli, J. Ayadi, M. Egido, Ubiquitous
Connectivity Platform for Public Transport Communication Services, Future
Network and Mobile Summit 2013, 3-5 July 2013, Lisboa, Portugal
3. [3] A. C. Hosu, Z. I. Kiss, Z. A. Polgar, A cellular - WLAN vertical handover
management system for public transport, 36th International Conference on Telecommunications and Signal Processing 2013 TSP 2013, 2-4 July 2013, Rome, Italy
4. [4] Z. I. Kiss, A. B. Rus, V. Dobrota, A. Consoli, M. Egido, Z. A. Polgar, Seamless
Connectivity Platform Architecture for Public Transportation, 21st International
Conference on Software, telecommunications and Computer Networks 2013, 1820 September 2013, Primosten, Croatia.
5. [5] A. C. Hosu, Z. I. Kiss, I. A. Ivanciu, Z. A. Polgar, A. Consoli, M. Egido, Ubiquitous Connectivity Platform for Intelligent Public Transportation Systems, 10th
ITS European Congress 2014, 16-19 June 2014, Helsinki, Finland.
6. [6] ISO 21210:2012: Intelligent transport systems-Communications access for
land mobiles (CALM)-IPv6 Networking, http://www.iso.org/iso/
121
Autori
Zsolt Alfred Polgar, Andrei Ciprian Hosu, Zsuzsanna Ilona Kiss,
Andrei Bogdan Rus, Gabriel Lazr, Virgil Dobrot
@ Departamentul Comunicaii, Universitatea Tehnic din Cluj Napoca
erban Meza
Activnd la Universitatea Tehnic din Cluj-Napoca, n cadrul Centrului de Tehnologii Multimedia i Educaiei la Distan, erban i pune n
practic pasiunea pentru sistemele video i multimedia n activitile de
cercetare i integrare a acestora n educaie i industrie. A fost activ implicat
n proiectele educaionale romneti www.didatec.ro, www.e-start.ro, www.e-administratie.forhe.ro si a colaborat cu compania Grass Valley Olanda
la realizarea camerelor video profesionale.
Actualmente este interesat de platforme educaionale social interactive
i de sistemele video 3D de realitate augmentat.
12
E-EDUCAIE I PLATFORME
EDUCAIONALE ONLINE
MULTIMEDIA SYSTEMS AND

APPLICATIONS LABORATOR
MSAL, anterior Centrul de Tehnologii Multimedia i Educaie la Distan
(CTMED), funcioneaz n cadrul Universitii Tehnice din Cluj-Napoca i
este dedicat att activitilor de cercetare aplicativ n domeniu ct i implementrii de soluii practice avnd la baz tehnologii multimedia. Astfel, pe
lista subiectelor de interes i n care sunt deinute competene se afl:
sisteme de e-educaie, blended learning i management educaional.
e-Sntate: platforme i aplicaii specifice de management sau de
prelucri i procesri de informaie medical (HIS, RIS, HL7, DIICOM, imagistic medical).
e-Mediu i platforme i sisteme de management inteligent al cldirilor.
e-Guvernare i administrare.
dezvoltarea de coninut digital interactiv, multimedia: foto, grafic 2D
i 3D, video 2D, 3D, 360, IR, realitate augmentat i virtual.
tehnici i tehnologii de reprezentare, codare i compresie a informaiilor multimedia i implementarea de standarde audio-video.
scriere i management / implementare de proiect.
Proiectele majore n zona educaional aflate n ultimii ani n implementare n cadrul colectivului sunt:
DidaTec -coala universitar de formare iniial i continu a personalului didactic i a trainerilor din domeniul specializrilor tehnice i ingi-
124
nereti finanare din Fonduri structurale, coordonator proiect fiind

Universitatea Tehnic din Cluj-Napoca.
eSTART - Program multi-regional de studii masterale n domeniul eActiviti finanare din Fonduri structurale, coordonator proiect fiind
Universitatea Tehnic din Cluj-Napoca.
eAdministraie Pregtirea sistemului naional de e-Administraie
n Romnia finanare din Fonduri structurale, coordonator proiect
Unitatea Executiv pentru Finanarea Invmntului Superior, a
Cercetrii, Dezvoltrii i Inovrii.
Proiectul DidaTec a avut ca scop implementarea eficient a tehnologiilor

i instrumentelor educaionale moderne n nvmntul superior tehnic.
Principalele rezultate au fost realizarea unui Program de Formare n Tehnologii Educaionale moderne dedicat cadrelor didactice din nvmntul
superior tehnic din Romnia i rularea acestuia n regim blended-learning n
rndul a peste 750 de persoane din grupul int. Competenele dezvoltate
au ajutat la transpunerea n format electronic (multimedia) de ctre acetia
Fig. 1 Scenarii de utilizare a platformei www.didatec.ro
125
a materialelor deinute pentru disciplina predat n funcie de specificul existent. Programul de Formare i materialele create pentru cele peste 750 de
discipline sunt accesibile prin intermediul platformei de management educaional dezvoltat n cadrul proiectului1. Tehnologia / platforma de implementare utilizat este MS SharePoint 2010. Imaginea urmtoare descrie
principalele scenarii de utilizare.
Proiectul eSTART a avut drept scop realizarea unui program profesional
de master derulat n regim de frecven redus i folosind platforme educaionale suport pe domeniul interdisciplinar al e-Activitilor i e-Serviciilor cu specializrile: Specialist platforme i servicii electronice n domeniul
medical i de sntate, Specialist platforme i servicii electronice n domeniul afacerilor (i bancar), Specialist platforme i servicii electronice n administraia public, Specialist platforme i servicii electronice new media. n
cadrul parteneriatului proiectului, n baza consultrilor cu partenerii sociali
implicai (mediul economic, studeni, cadre didactice, etc.), s-a dezvoltat ntregul curriculum necesar derulrii programului de studii i s-a implementat
o platform de e-learning specific. Rezultate disponibile n acest sens gsii
la adresa www.e-start.ro. Platforma de implementare utilizat este Moodle.
Detalii generale legate de structura curriculumului sunt prezente n figura
urmtoare:
Fig. 2 Structura curriculumului Programului de master eSTART

1 www.didatec.ro
126
Proiectul eAdministraie s-a adresat funcionarilor publici din Romnia

i a avut drept scop implementarea unei platforme educaionale online pentru pregtirea acestora n vederea dezvoltrii competenelor legate de utilizarea tehnologiei informaiei n actul de guvernare i administrare. MSAL s-a
implicat n definirea setului de cursuri oferite n cadrul proiectului precum
i n implementarea i pilotarea a dou dintre acestea: Coninut electronic
pentru e-Administratie i, respectiv, Proiectarea i implementarea fluxurilor de documente electronice. Platforma cu materialele educaionale din
proiect, implementat folosind platforma Ilias, este disponibil la adresa
http://learning.forhe.ro/.
Autor
dr.ing.ec. erban-Nicolae MEZA - ef lucrri @ Universitatea Tehnic
din Cluj-Napoca, n cadrul Centrului de Tehnologii Multimedia i
Educaiei la Distan
127
Silviu Dumitrescu
Dup cum probabil tii sunt braovean, fapt de care sunt foarte mndru.
Am dou licene: n inginerie i n matematic-informatic (pe vremea n
care licena dura 5 ani), un masterat n informatic (jumtate fcut la Universitatea din Oldenburg) i un doctorat n informatic, avndu-l ca mentor pe
dl. academician Solomon Marcus, un profesor i un om absolut remarcabil.
Toat viaa mea mi-am petrecut-o ntre nevoia de a studia, nelege, inova
i dorina de a fi apropiat de tehnologie, de a fi productiv, de a arta ceea ce
am nvat.
Acestea s-au concretizat n educarea multor generaii de oameni crora
am ncercat, i ntr-o bun msur am reuit, s le transmit ideea de a nu se
lsa condui de interese mici, de moment. Pe de alt parte am proiectat i
dezvoltat aplicaii bine vndute i foarte apreciate, am scris cri i articole.
Ca personalitate pot spune c sunt, aa cum o persoan foarte apropiat
declara, complex, fac multe activiti complementare care m ndeprteaz
de viaa monoton, cotidian. Nu v spun ce carte am citit ultima oar, dar v
spun ultimul concert la care am fost: Lenny Kravitz, Munich, 15 noiembrie
2014 (ncnttor).
mi place s triesc printre oameni i de foarte puine ori am dezamgit,
iar cnd iubesc, arareori iubesc, o fac cu tot sufletul meu i mult n plus.
13
JAVA STANDARD 8,
NOUTI I MBUNTIRI
Cartea care nsoeste evenimentul IT Days din acest an, 2014, are titlul
Cum s construieti un proiect IT. Deosebit de generos ca ntindere i ca
subiecte posibil de abordat, titlul i gsete i o important latur tehnic,
pe care o voi dezvolta din prisma noutilor de pe piaa dezvoltarilor de soft
ce folosesc lumea Java. Versiunea 8 a limbajului standard lansat anul acesta
aduce numeroase nouti. Cred c pentru oricine este implicat n munca de
dezvoltare a aplicaiilor Java, o trecere n revist a acestor nouti este binevenit, util i interesant.
Prima parte a articolului aduce n atenie cele mai importante repere ale
versiunii, cel puin din perspectiva autorului. A doua parte este mult mai
pragmatic i vine n ntmpinarea nevoilor unei echipe de dezvoltare, care-i dorete s pun n valoare avantajele implementrilor predefinite ale
design pattern-ilor, ale numeroasele API-uri cu funcii grafice, n a crea clieni rich folosind Java ntr-un mod mai facil, mai productiv avnd consecine
importante n creterea calitii soft-ului.
Java SE8 este considerat revoluionar prin cteva dintre noile caracteristici introduse. Programat iniial pentru luna septembrie 2013, lansarea a
fost amnat pentru martie 2014. Motivele sunt numeroase, dar in n special
de corectarea bug-urilor i mbuntirea securitii, mai ales pe acelea legate
de client, avnd ca principal motiv JavaFX.
130
LAMBDA EXPRESII I PROCESAREA COLECIILOR

Multe sunt modificrile i adugrile fcute n limbaj, dar probabil cea
mai spectaculoas este introducerea capabilitilor lambda. Acestea sunt vzute ca un important beneficiu n programarea paralel. De fapt, eforturile
pentru creterea performanei n programarea paralel s-au vzut nc din
versiunea 7, introducerea framework-ului Fork-Join este un exemplu.
O funcie lambda (funcie anonim) este o funcie definit i apelat fr
a fi legat de un identificator. Funciile lambda sunt o form de funcii ncuibate (nested functions) n sensul c permit accesul la variabilele din domeniul
funciei n care sunt coninute.
Funciile anonime au fost introduse de ctre Alonzo Church n anul
1936, n teoria sa despre calculele lambda (http://en.wikipedia.org/wiki/
Lambda_calculus). n limbajele de programare funciile anonime au fost implementate nc din anul 1958, ca parte a Lisp.
n limbajele orientate pe obiect, precum Java, apar concepte similare,
precum clasele anonime. Totui, Java abia n versiunea 8 implementeaz
funciile anonime. Alte limbaje, C#, JavaScript, Perl, Python, Ruby, ofereau
de mult suport pentru acest concept.
Lambda expresiile ne permit s crem instane ale claselor cu o singur
metod, ntr-un mod mult mai compact.
O lambda expresie const din:
o list de parametri formali, separai prin virgul i cuprini eventual
ntre paranteze rotunde,
o sgeat direcional ->,
un body ce const dintr-o expresie sau un bloc de instruciuni.
O interfa funcional (functional interface), anotat @FunctionalInterface, este orice interfa ce conine doar o metod. Deoarece interfaa
funcional are o singur metod, putem omite numele metodei la implementare i putem astfel elimina folosirea claselor anonime, cu implicaii n
creterea performanei. n locul claselor anonime folosim lambda expresii.
Pentru a nelege modul n care se lucreaz cu lambda expresii am construit un mic exemplu prin care am creat colecii de obiecte sortate dup
diverse criterii. Implementarea interfeei Comparator a fost fcut ntr-o
clas anonim, folosind lambda expresii. Implementarea cu lambda expresii
a fost posibil pentru c n versiunea 8 Comparator este anotat cu @FunctionalInterface.
131
Elementul de baz al coleciei este clasa Product, care este o clas POJO
cu getter-i si setter-i. Clasa conine dou implementri anonime ale comparatorului, determinnd sortarea cresctoare respectiv descresctoare a elementelor coleciei.
package model;
import java.util.Comparator;
public class Product {

private String name;

private int price;

public String getName() {

return name;
}

public void setName(String name) {

this.name = name;
}

public int getPrice() {

return price;
}

public void setPrice(int price) {

this.price = price;
}

public void printProduct() {

System.out.println(this.toString());
}

@Override

public String

return
];
}

public static
{

return
};

-> {
toString() {
Product [name= + name + , price= + price +
Comparator<Product> ascendingPrice = (p1, p2) ->

p1.getPrice() - p2.getPrice();
public static Comparator<Product> descendingPrice = (p1, p2)
132

};
}
return p2.getPrice() - p1.getPrice();
Clasa de test va aduce ceva n plus fa de o clas folosit pn n versiunea 8 i anume procesarea coleciei, care nu se va face ntr-un foreach clasic.
Ca parte a API-ului Collections avem noul API java.util.stream ce
ofer suport pentru operaii funcionale pe stream-uri de elemente. n exemplul nostru vom folosi o interfa de baz a acestui API i anume Consumer, care reprezint o operaie ce accept un singur argument de intrare i
nu returneaz ceva. Cu Consumer vom putea folosi lambda expresii:
import java.util.Set;
import java.util.TreeSet;
import java.util.function.Consumer;
import model.Product;
public class TestLambda {

public static void processProducts(Set<Product> products,
Consumer<Product> block) {

for (Product p : products) {

block.accept(p);

}
}

public static void main(String[] args) {
Product p1 = new Product();

p1.setName(onion);

p1.setPrice(10);
Product p2 = new Product();

p2.setName(tomato);

p2.setPrice(20);
Set<Product> ascendingPriceProducts = new TreeSet<>(
Product.ascendingPrice);

ascendingPriceProducts.add(p1);

ascendingPriceProducts.add(p2);
System.out.println(In ascending order:);

processProducts(ascendingPriceProducts, p -> p.printProduct());
Set<Product> descendingPriceProducts = new TreeSet<>(
133
Product.descendingPrice);
descendingPriceProducts.add(p1);
descendingPriceProducts.add(p2);
System.out.println(\nIn descending order:);
processProducts(descendingPriceProducts, p -> p.printProduct());
}
}
Ca urmare a folosirii API-ului, stream-operaiile efectuate pe o colecie,

numite i operaii agregat, pot fi mult mai complexe dect cele ilustrate n
exemplu i anume: filtrarea dup un predicat de selecie, maparea obiectului
filtrat, respectiv executarea unei aciuni pe fiecare obiect mapat. Eu am prezentat doar ultima operaie.
Observaia pe care vreau s o fac codului anterior este c implementarea
comparatorului ine loc de suprascriere a funciei equals(), fapt ce poate fi
dovedit prin modificarea, n cod, la aceeai valoare a preului.
ENGINE-UL JAVASCRIPT NASHORN
Pe lng lambda expresii, o caracteristic important a platformei standard 8 este dezvoltarea engine-ului JavaScript Nashorn (se pronun nazhorn). Prin acesta se pot integra script-uri JavaScript n codul Java clasic.
Acest engine se bazeaz pe standardul ECMAScript 262. Este un engine
scris complet de la zero, avnd ca obiectiv creterea performanei. Este astfel
complet diferit fa de engine-ul deja existent Rhino.
Voi da doar un exemplu de folosire a acestui engine:
import javax.script.*;
public class EvalScript {

public static void main(String[] args) throws Exception {

ScriptEngineManager factory = new ScriptEngineManager();
ScriptEngine engine = factory.getEngineByName(nashorn);

try {

engine.eval(print(Hello, World!););

} catch (final ScriptException se) {

se.printStackTrace();

}
}
134
Rulnd acest exemplu vom obine la consol mesajul Hello, World!.

ELEMENTE AVANSATE
n seciunea final a primei pri aduc n discuie anumite elemente cu un
nivel de dificultate mai ridicat, pentru a permite evidenierea unor aspecte de
performan, productivitate i de reducere a dimensiunii codului scris.
Pentru nceput revin la lambda expresii. Prin lambda expresii putem crea
metode anonime. Uneori ns, lambda expresiile apeleaz metode care au
deja un nume.
Am definit ntr-una dintre seciunile anterioare o clas Product cu
dou atribute: name i price, getter-i i setter-i. Voi mai aduga proiectului
nostru o clas POJO n care se afl diverse metode de comparare, cu semnturi apropiate de ale metodei compare() din interfaa Comparator:
public class ProductComparisons {

public int compareByName(Product a, Product b) {

return a.getName().compareTo(b.getName());
}

public int compareByPrice(Product a, Product b) {

return a.getPrice() - b.getPrice();
}
}
n clasa de test vom crea dou obiecte Product, p1 i p2, pe care le vom
pune ntr-un array:
Product[] basket = { p1, p2 };
Vom sorta array-ul folosind lambda expresii:
ProductComparisons myComparison = new ProductComparisons();
Arrays.sort(basket, (a,b)->myComparison.compareByName(a, b));
Aceast sintax este posibil pentru c rezultatul lambda expresiei este o

clas anotat @FunctionalInterface, n cazul nostru, Comparator.
n locul folosirii lambda expresiilor, Java SE8 ofer posibilitatea utilizrii
referinelor de metode, prin intermediul operatorului de domeniu ::. Sintaxa este astfel mult simplificat.
Revin la exemplul nostru i aplic operatorul menionat. Sintaxa devine:
135
Arrays.sort(basket, myComparison::compareByName);
Avem urmtoarele tipuri de referine:

La o metod a unui obiect (exemplul anterior);
La o metod static (exemplul anterior poate fi uor customizat);
La o metod a unui obiect arbitrar de un tip particular;
Arrays.sort(stringArray, String::compareToIgnoreCase);
La un constructor:
Supplier<Product> s = Product::new;
unde, Supplier este din java.util.function.Supplier.

Un alt subiect supus ateniei este legat de interfee. Interfeele conineau
pna la aceasta versiune doar semnturi de metode i constante. Java 8 propune o abordare care s mbunteasc utilizabilitatea interfeelor. Dac
adaugm noi semnturi n interfa, atunci clasele ce o implementeaz ar
trebui rescrise. Pentru a evita procesul rescrierii s-au introdus metodele default. Pe lng semnturi i constante, interfeele vor conine astfel i implementri.
Voi da un exemplu simplu care s evidenieze noile abordri:
public interface MyInterface {

void myClassicMethod();

default void myDefaultMethod() {

System.out.println(hello default!);
}

static void myStaticMethod(){

System.out.println(hello static!);
}
}
Respectiv clasa ce implementeaz interfaa:

public class MyClass implements MyInterface {

@Override

public void myClassicMethod() {

System.out.println(hello classic!);
136
}
}
Ca test avem:
MyInterface mine = new MyClass();

mine.myClassicMethod();

mine.myDefaultMethod();
MyInterface.myStaticMethod();
}
Surprindem astfel cele trei comportamente:

Cel predefinit, cu calificatorul public abstract
(Ex: myClassicMethod()),
Cel cu implementare default,
Cel cu implementare static default.
Procesul de motenire are suport i pentru acest nou comportament. Astfel:
Metodele default care nu sunt menionate n interfaa derivat motenesc comportamentul default din interfaa de baz.
Metodele default redeclarate n interfaa derivat devin abstracte.
Metodele default redefinite n interfaa derivat vor fi folosite suprascris.
Nu voi incheia acest articol fr s descriu cteva dintre API-urile folosite
n discuiile anterioare:
java.util.function furnizeaz interfeele funcionale ce sunt returnate ca tip de ctre lambda expresii. Interfeele funcionale reprezint concepte abstracte precum funciile, aciunile sau predicatele.
java.util.stream furnizeaz clase pentru operaii pe stream-uri
de elemente. Stream-urile difer de colecii prin:
stream-ul nu este o structur de date, ci transform o structur
de date ntr-un pipeline de operaii.
o operaie pe un stream produce o operaie, dar nu modific
sursa.
operatiile pe stream-uri sunt implementate lazy, ceea ce nseamn c pot expune oportuniti de optimizare.
stream-urile sunt practic infinite. Exist i operatii de scurt-cir-
137
cuitare care s produc ieiri ntr-un timp finit (limit(), findFirst()) .

stream-urile sunt consumabile, adic elementele sunt vizitate o
singur dat. Pentru o revizitare trebuie creat un alt stream.
toate clasele wrapper (Boolean, Integer, etc.) au fost mbuntite
cu metode care folosesc lambda expresi i referine de metode.
JAVAFX - INTRODUCERE
JavaFX este urmaa lui F3 (Form Follows Function) ce l are ca printe

pe Chris Oliver. n 2010, Oracle a anunat c dezvoltarea lui JavaFX Script
language va fi ntrerupt, n schimb aceasta se va porta pe Java, formnd platforma JavaFX 2. Prin aceasta se puneau bazele ca JavaFX s devin cel mai
important mediu pentru aplicaii rich client.
API-ul JavaFX este rulat de un engine compus din subcomponente. Acesta cuprinde noul engine grafic de nalt performan numit Prism, sistemul
eficient de windowing numit Glass i un engine media.
Glass Windowing Toolkit este responsabil cu furnizarea unui serviciu
nativ ce include gestiunea ferestrelor, a timer-elor i a suprafeelor. De asemenea, leag platforma JavaFX de sistemul de operare nativ. Mai mult, Glass
este responsabil de gestiunea cozii de evenimente. Dac AWT i gestioneaz propria coad de evenimente, Glass utilizeaz coada nativ a sistemului de
operare. Glass Toolkit ruleaz n acelai fir ca i aplicaia JavaFX, n timp ce
n AWT, spre exemplu, se crea un fir de execuie paralel cu cel al Javei.
O aplicaie rich client este o aplicaie ce are o interfa care refer backend-ul fr a aglomera astfel interfaa utilizator. JavaFX are un set complet
de butoane, diagrame, tabele i container-e de layout pe care le folosim pentru
a crea interfee utilizator rich. n plus, putem folosi stiluri CSS. Toate componentele se conecteaz i afieaz date din backend.
n general, o aplicaie rich-client are urmtoarele caracteristici:
Este o aplicaie stand alone executabil.
Conine o interfa utilizator ce are controale sau formulare.
Este descrcabil din desktop sau web.
Se conecteaz la o baz de date i un server de backend.
Este independent fa de sistemul de operare.
O aplicaie JavaFX este o aplicaie Java de baz, ce permite feature-uri
138
JavaFX. Codul minim necesar pentru a rula o aplicaie JavaFX const din:
O clas ce extinde clasa abstract javafx.application.Application;
O metod main() ce apeleaz metoda launch() i suprascrie metoda abstract start(). Ca bun practic, apelul metodei launch()
este singurul apel din main();
Un stage primar ce este vizibil ca argument al metodei start().
Avem trei tipuri de aplicaii JavaFX:
Aplicaii propriu- zise, ce folosesc sintaxa Java tradiional i API-ul
JavaFX.
Aplicaii FXML. FXML se bazeaz pe XML i este folosit pentru a
defini interfee utilizator n aplicaii JavaFX. Cu FXML vom defini
layout-uri statice precum formulare, controale sau tabele. Putem construi de asemenea layout-uri dinamice prin includerea unui script.
Aplicaii preloader, folosite n procesul de deployment
import javafx.application.Application;
import javafx.stage.Stage;
public class JavaFXApplication extends Application {

@Override

public void start(Stage stage) {

stage.show();
}


launch(args);
}
}
Un stage (javafx.stage.Stage) este un container GUI,nivel de top

pentru toate obiectele grafice, iar un scene (javafx.scene.Scene) este
container-ul de baz. Stage-ul primar este construit de platform, dar pot fi
construite i alte obiecte stage de ctre aplicaie. Obiectele stage trebuie s fie
construite i modificate n firul aplicaiei JavaFX.
Articolele individuale care se afl n interiorul scenei grafice sunt numite
noduri. Fiecare nod este clasificat ca fiind unul dintre:
Branch sau printe, ceea ce nseamn c poate avea descendeni.
139
Frunz.
Primul nod din arbore este numit rdacin i nu are printe.
Scena grafic este aadar o structur arborescent. API-ul JavaFX face ca
interfaa grafic s fie mai uor de creat, mai ales cnd sunt implicate efecte
vizuale complexe i transformri.
API-ul scenei grafice JavaFX este un retained mode, adic el gestioneaz
un model intern al tuturor obiectelor grafice din aplicaie. n orice moment
el tie ce obiecte s afieze, ce zone ale ecranului necesit redesenare i cum
s fie renderizat n cel mai eficient mod. Aceasta reduce semnificativ cantitatea de cod necesar n aplicaie.
mbuntesc aplicaia anterioar prin adugarea unui buton cu text i al
unui container de layout. Butonul va fi un nod frunz, iar StackPane-ul nod
rdcin.
import
import
import
import
import
import
import
javafx.application.Application;
javafx.event.ActionEvent;
javafx.event.EventHandler;
javafx.scene.Scene;
javafx.scene.control.Button;
javafx.scene.layout.StackPane;
javafx.stage.Stage;
public class JavaFXApplication extends Application {

launch(args);
}
@Override
public void start(Stage primaryStage) {
primaryStage.setTitle(Hello World!);
Button btn = new Button();
btn.setText(Say Hello World);
btn.setOnAction(new EventHandler<ActionEvent>() {
@Override
public void handle(ActionEvent event) {

System.out.println(Hello World!);
}
});
StackPane root = new StackPane();
140
root.getChildren().add(btn);
primaryStage.setScene(new Scene(root, 300, 250));
primaryStage.show();
}
}
Voi dezvolta o aplicaie echivalent folosind FXML. FXML ofer urmtoarele avantaje:
Fiind bazat pe XML este familiar multor dezvoltatori, n special dezvoltatorilor web i celor care utilizeaz alte platforme RIA.
FXML nu se compileaz, de aceea modificrile sunt mult mai uor
de fcut.
Asigur o structur uor vizibil a aplicaiei.
Cnd crem o aplicaie JavaFX FXML avem de creat trei fiiere:
Clasa main ce conine cod pentru crearea scenei aplicaiei, a stage-ului
i pentru lansarea aplicaiei. Una dintre aciunile importante este dat
de secvena urmtoare:
Parent root=null;

try {

root = FXMLLoader.load(getClass().getResource(Sample.fxml));
} catch (IOException e) {

e.printStackTrace();
}
stage.setScene(new Scene(root));
Metoda FXMLLoader.load() ncarc ierarhia de obiecte din fiierul de

resurse Sample.fxml i o asigneaz variabilei numite root. Aceast clas
este Model-ul n pattern-ul MVC. Ultima parte a aciunii este setarea scenei.
Fiierul Sample.fxml este fiierul n care construim interfaa utilizator :
<?xml version=1.0 encoding=UTF-8?>
<?import javafx.scene.layout.AnchorPane?>
<?import javafx.scene.control.Button?>
<?import javafx.scene.control.Label?>
<AnchorPane id=AnchorPane prefHeight=200 prefWidth=320
xmlns:fx=http://javafx.com/fxml fx:controller=henleyclient.Sample>
141

<children>
<Button id=button layoutX=126 layoutY=90 text=Click Me!
onAction=#handleButtonAction fx:id=button />
<Label id=label layoutX=126 layoutY=120 minHeight=16
minWidth=69 prefHeight=16 prefWidth=69 fx:id=label />

</children>
</AnchorPane>
Acest fiier reprezint View-ul n pattern-ul MVC. Nodul rdcin este

AnchorPane, iar nodurile descendeni sunt Button i Label.
Fiierul Sample.java este fiierul controller al interfeei utilizator.
Numele acestuia trebuie s fie identic cu cel al clasei view fxml.
import java.net.URL;
import java.util.ResourceBundle;
import
import
import
import
javafx.event.ActionEvent;
javafx.fxml.FXML;
javafx.fxml.Initializable;
javafx.scene.control.Label;
public class Sample implements Initializable {

@FXML
private Label label;
@FXML
private void handleButtonAction(ActionEvent event) {
System.out.println(You clicked me!);
label.setText(Hello World!);
}
@Override
public void initialize(URL url, ResourceBundle rb) {
// TODO
}
}
Aplicaiile din acest articol au fost dezvoltate folosind Eclipse Luna, ca

proiecte Java Standard n care am inclus pachetul lib\jfxrt.jar.
142
CONCURENA N JAVAFX
Pachetul javafx.concurrent gestioneaz codul multifir al interaciunii
cu UI-ul i asigur ca aceast interaciune s aib loc n firul corect. Pachetul
const din interfaa Worker i dou clase de baz: Task i Service, ambele
implementnd interfaa Worker.
Interfaa Worker furnizeaz API-ul folosit de un background worker
ce comunic cu UI-ul. Clasa Task este o implementare complet observabil
a clasei java.util.concurrent.FutureTask i permite dezvoltatorilor
s implementeze task-uri asincrone n aplicaiile JavaFX. Clasa Service execut aceste task-uri.
Un Worker este aadar un obiect ce lucreaz ntr-un fir din background.
Starea obiectului Worker este observabil i utilizabil din firele aplicaiei
JavaFX.
Ciclul de via al lui Worker este definit astfel: cnd este creat obiectul
Worker este n starea READY. Dup ce a fost programat pentru lucru, obiectul Worker tranziteaz ctre starea SCHEDULED. Dup aceea, cnd obiectul
Worker ruleaz, starea sa devine RUNNING.
Observaie: chiar dac obiectul Worker a pornit imediat, fr a fi programat, el tranziteaz totui n starea SCHEDULED i apoi n RUNNING.
Starea obiectului Worker, atunci cnd se execut cu succes, devine SUCCEEDED, iar proprietatea valoare va fi setat la rezultatul obiectului Worker. Altfel, dac sunt aruncate excepii pe timpul execuiei obiectului Worker, starea sa devine FAILED, iar proprietatea excepie este setat la tipul de
excepie aprut. n orice stare obiectul Worker poate fi ntrerupt utiliznd
metoda cancel(), ceea ce trimite obiectul n starea CANCELLED.
Progresul nregistrat la rularea obiectului Worker poate fi obinut prin
trei proprieti diferite: totalWork, workDone i progress.
Clasa Task poate fi pornit n unul dintre urmtoarele moduri (primele
dou ar fi preferabile):
Folosind ExecutorService API: ExcecutorService.submit(task);
Utiliznd metoda task.run();

Pornind un fir cu task-ul dat ca parametru: new Thread(task).
start();
Task-urile sunt utilizate pentru a implementa logica de lucru ntr-un fir

din background. Pentru nceput trebuie s extindem clasa Task, care va suprascrie metoda call(). Clasa Task motenete clasa java.utils.con-
143
current.FutureTask, ce implementeaz interfaa Runnable. De aceea,

obiectul Task poate fi utilizat cu API-ul Executor i poate fi trimis unui fir,
ca parametru.
Putem apela obiectul Task direct prin FutureTask.run(), ceea ce ne
permite s apelm acest task dintr-un alt fir.
Vom crea o clas CounterTask ce extinde clasa Task.
public class CounterTask extends Task<Void> {

@Override

public Void call() {

final int max = 10000000;

updateProgress(0, max);

for (int i = 1; i <= max; i++) {
updateProgress(i, max);

}

return null;
}
}
Metoda call() este invocat de firul din background, de aceea aceast

metod poate manipula stri ce sunt sigure a fi citite sau scrise dintr-un fir
din background. Spre exemplu, manipularea scenei grafice active din metoda
call() va arunca o runtime exception.
Pe de alt parte, clasa Task este destinat a fi utilizat cu aplicaii JavaFX i ne asigur c orice modificri ale proprietilor publice, notificri de
eroare, manipulatoare de evenimente i stri apar n firul aplicaiei JavaFX.
n interiorul metodei call() putem utiliza metodele: updateProgress(),
updateMessage() i updateTitle()pentru a updata valorile corespunztoare proprietilor pe firul JavaFX.
n aplicaie am creat o instan a clasei anterioare, numit countTask i
am executat-o printr-un: ExecutorService (ExecutorService es = Executors.newSingleThreadExecutor();):
@Override
System.out.println(Count Started);

bar.progressProperty().bind(countTask.progressProperty());

es.execute(countTask);
}
Clasa Service este destinat executrii unui obiect Task dintr-unul sau
mai multe fire. Metodele i strile clasei Service trebuie accesate din firul
aplicaiei JavaFX. Aceast clas ajut dezvoltatorii s implementeze o inter-
144
aciune corect ntre firele din background i firul aplicaiei JavaFX. Putem
porni, opri, anula i restarta un Service. Un Service poate rula un task
mai mult dect o dat. Aadar, un serviciu poate fi definit declarativ i restartat la cerere.
Un Service poate fi executat n unul dintre urmtoarele modaliti:
De un obiect Executor, dac este specificat pentru serviciul dat;
De un fir daemon, dac niciun Executor nu este specificat;
De un executor custom precum ThreadPoolExecutor;
Exemplu de creare a unui service custom este dat n exemplul de mai jos:
public class CounterService extends Service<Void> {

@Override

protected Task<Void> createTask() {

CounterTask ct = new CounterTask();

return ct;
}
}
Creez n aplicaia JavaFX un:

CounterService (CounterService cs = new CounterService();)
i pornesc firul astfel:

if (cs.getState() == State.READY) {

cs.start();
}
DATA BINDING N JAVAFX

Data binding-ul are rolul de a simplifica task-ul sincroniznd view-ul cu
datele din model. Legarea (binding-ul) observ listele sale de dependene
pentru a detecta schimbri i se auto-updateaz dac acestea au aprut. APIul de binding furnizeaz un mod simplu de a crea legri pentru cele mai
comune situaii.
Binding-ul este aadar un mecanism puternic pentru exprimarea relaiilor
directe dintre variabile. Cnd obiectele particip la legturi, modificrile
efectuate unuia vor fi automat reflectate celuilalt. Spre exemplu, binding-ul
poate fi utilizat n GUI pentru pstrarea automat a afirilor sincronizate cu
datele pe care le refer.
Binding-urile sunt asamblate din una sau mai multe surse numite de-
145
pendene.
n exemplul nostru anterior am folosit funcia bind() pentru a lega progress bar-ul de counterTask.
Iat codul complet al aplicaiei JavaFX:
public class CounterBarAppService extends Application {
StackPane root = new StackPane();
VBox mainBox = new VBox();
ProgressBar bar = new ProgressBar(0.0);
CounterService cs = new CounterService();

@Override

public void init() throws Exception {

super.init();

mainBox.setAlignment(Pos.CENTER);
mainBox.setSpacing(10);
Button btn = new Button();

btn.setText(Count to Ten Million!);
btn.setOnAction(new EventHandler<ActionEvent>() {

@Override



bar.progressProperty().bind(cs.progressProperty());

if (cs.getState() == State.READY) {
cs.start();
}

}
});

Button restartBtn = new Button();
restartBtn.setText(Restart);
restartBtn.setOnAction(new EventHandler<ActionEvent>() {

@Override



bar.progressProperty().bind(cs.progressProperty());

cs.restart();

}
});

mainBox.getChildren().add(btn);
mainBox.getChildren().add(restartBtn);
146

}

mainBox.getChildren().add(bar);
root.getChildren().add(mainBox);

@Override

public void stop() throws Exception {

super.stop();
}


launch(args);
}

@Override


primaryStage.setTitle(JavaFX Service Example);

}

INSTRUMENTE GRAFICE DE AFIARE A

COLECIILOR N JAVAFX
Tabelele reprezint unul dintre cele mai puternice instrumente folosite n
JavaFX pentru afiarea datelor, suportnd urmtoarele aciuni:
Reordonarea coloanelor afiate de ctre utilizator,
Sortarea multipl a coloanelor,
Redimensionarea,
Factories de celul pentru customizarea coninutului celulei.
Mai multe clase din JavaFX SDK API sunt folosite pentru reprezentarea datelor n form tabelar. Dintre acestea cele mai importante sunt
TableView, TableColumn i TableCell. Putem popula un tabel dintr-un
model de date i i putem aplica apoi un cell factory.
TableView are faciliti ce includ:
API-ul TableColumn:
Suport pentru cell factories, ce permite o customizare a coninutului celulei n ambele stri: de afiare i de editare;
Specificarea dimensiunilor: minWidth, prefWidth, maxWidth,
a coloanelor de dimensiune fix;
147
Redimensionarea la rulare de ctre user ;

Reordonarea la rulare coloanelor de ctre user;
Suport pentru ncuibarea coloanelor;
Diferite politici de redimensionare care determin ce se ntmpl
atunci cnd utilizatorul redimensioneaz coloanele;
Suport pentru sortarea pe mai multe coloane prin apsarea header-ului de coloan (apsnd tasta Shift n timp ce facem click pe header);
Minimal avem nevoie de clasele urmtoarele pentru a crea un tabel:
TableView<S>, unde S este tipul obiectului ce conine lista itemilor
din TableView;
TableColumn<S, T>, unde S este varianta tipului generic TableView, iar T este tipul coninutului tuturor celulelor din acest TableColumn.
TableView este construit dintr-un numr de instane TableColumn.

Fiecare TableColumn este responsabil de afiarea i editarea coninutului
unei coloane. n plus, TableColumn conine proprieti pentru:
Redimensionare,
Vizibilitate,
Afiarea textului de header,
Afiarea coloanelor ncuibate pe care le poate conine,
Afiarea unui meniu de context atunci cnd utilizatorul face click
dreapta pe zona capului de coloan,
Posibiliti de sortare.
Cnd crem o instan TableColumn, probabil cele mai importante proprieti de setat sunt textul (adic ce afim n capul de tabel al coloanei) i
cell value factory (utilizat pentru popularea celulelor individuale din coloan).
Clasa TableCell<S,T> reprezint intersecia unei linii cu o coloan n
TableView. Conine urmtoarele proprieti:
tableColumn: instana TableColumn din spatele TableCell,
tableView, TableView-ul asociat cu TableCell,
tableRow, TableRow-ul n care TableCell-ul este plasat.
Pentru a identifica intersecia TableCell conine o proprietate de index.
Cell<T> este utilizat pentru o celul individual ntr-un TableView.
148
Fiecare celul este asociat unui singur item de date, reprezentat de proprietatea item. O celul este responsabil de renderizarea item-ului care rezid
n el, care este de obicei un text. O celul permite customizarea printr-un cell
factory.
API-ul Cell este utilizat pentru virtualizarea controalelor precum ListView, TreeView i TableView. Un Cell este un control etichetat, folosit
pentru a renderiza o unitate ntr-unul dintre controalele mai sus amintite.
Cell este responsabil att pentru afiare ct i pentru editarea itemului. Pe
lng text, Cell poate fi reprezentat de alte controale precum CheckBox,
ChoiceBox sau orice Node precum HBox, GridPane sau chiar Rectangle.
Deoarece ListView, TreeView, TableView precum i alte asemenea
controale pot fi folosite pentru afiarea unei cantiti mari de date, nu este
practic s crem un Cell pentru fiecare item din control. Fiecare celul este
reutilizat, ceea ce face acest control virtualizat.
Deoarece Cell este un Control, el are n spate un model. Skin-ul su
este responsabil pentru definirea look and layout-ului, n timp ce Behaviour
este responsabil pentru manipularea evenimentelor i utilizarea acelor informaii coninute pentru a modifica starea. Cell este stilizat prin CSS ca
orice alt control.
Pentru a specializa o celul utilizat pentru un TableView trebuie s
furnizm o implementare a funciei callback cellFactory() definit pe
TableView. Cell factory este apelat de platform ori de cte ori o nou celul trebuie s fie creat. Implementarea unui cell factory este responsabil
pentru crearea unei instane Cell i pentru configurarea necesar pentru ca
Cell s reacioneze la schimbrile strii sale.
Cell factory este responsabil de virtualizarea skin-urilor de container pentru a renderiza reprezentarea predefinit a unui item Cell. Spre exemplu,
ntr-un ListView convertete itemii la un String i apeleaz Labeled.
setText(String). Dac dorim s specializm celula utilizat n ListView
trebuie s furnizm implementarea funciei callback definit pe ListView.
Cell factory este apelat de platform ori de cte ori determin c o celula
trebuie s fie creat.
Spre exemplu, un ListView are 10 milioane de itemi. Crearea tuturor
celor 10 milioane este foarte costisitoare. Aadar, implementarea skin-ului
ListView va crea doar attea celule ct s umple spaiul vizual. Dac se
redimensioneaz spaiul vizual, sistemul va determina dac este nevoie de
crearea altor celule. n acest caz va apela cellFactory() (dac exist vre-
149
una) pentru a crea o implementare Cell. Dac nu este furnizat niciuna,

implementarea predefinit este utilizat.
ObservableList este modelul de date care st la baza lui TableView. O
instan TableView este definit astfel:
TableView<Person> table = new TableView<>();
Am definit astfel un tabel primar. Modelul de date este creat pe baza unui
ObservableList. l putem seta direct n TableView. Spre exemplu:

ObservableList<Person> teamMembers = getTeamMembers();
table.setItems(teamMembers);
O dat setat lista de itemi TableView este automat updatat ori de

cte ori lista teamMembers se modific. Dac lista de itemi este disponibil
nainte ca TableView s fie instaniat este posibil s o trimitem direct n
constructor.
Ceea ce mai trebuie s facem este s mprim datele coninute n model
n una sau mai multe instane TableColumn. Pentru a crea un TableView
cu dou coloane, ce afieaz firstName i lastName vom folosi codul:
public class DataTable extends Application {
TableView<Person> table = new TableView<>();
BorderPane root = new BorderPane();
VBox mainBox = new VBox(); // Container for content

final ObservableList<Person> teamMembers = FXCollections
.observableArrayList(new Person(Ion, Tech),
new Person(Petre,Petrescu), new Person(Doru, Dorescu), new
Person(
Vasile, Vasilescu));

@Override
public void init() {
Label centerLbl = new Label(Persons);

centerLbl.setStyle(-fx-font-size:16pt; -fx-font-weight:bold;);
table.setItems(teamMembers);
TableColumn<Person, String> firstNameCol = new TableColumn<Person,
150
String>(First Name);
firstNameCol .setCellValueFactory(new PropertyValueFactory<Person,
String>(firstName));
TableColumn<Person, String> lastNameCol = new TableColumn<Person,
String>(Last Name);
lastNameCol.setCellValueFactory(new PropertyValueFactory<Person,
String>(lastName));
table.getColumns().setAll(firstNameCol, lastNameCol);
mainBox.getChildren().add(centerLbl);
mainBox.getChildren().add(table);
}

@Override


primaryStage.setTitle(Data Table);

root.setCenter(mainBox);
}


launch(args);
}
}
Prin aceasta am definit complet proprietile minime cerute pentru a crea

o instan TableView. Nici o alt proprietate a clasei Person nu va fi afiat
pentru c nu avem definite alte TableColumn.
Implementarea unui cell factory este responsabil nu doar pentru crearea instanei Cell, dar i pentru configurarea acelei celule. n exemplul urmtor am creat o clas Callback ce are ca atribute instane ale claselor
TextAlignment i Format cu parametri:
S, tipul generic al lui TableView;
T, tipul coninutului n toate celulele lui TableColumn
public class FormattedTableCellFactory<S, T> implements

Callback<TableColumn<S, T>, TableCell<S, T>> {

private TextAlignment alignment;

private Format format;

public TextAlignment getAlignment() {

return alignment;
151
}

public void setAlignment(TextAlignment alignment) {

this.alignment = alignment;
}

public Format getFormat() {

return format;
}

public void setFormat(Format format) {

this.format = format;
}

@Override

public TableCell<S, T> call(TableColumn<S, T> p) {

TableCell<S, T> cell = new TableCell() {

@Override

public void updateItem(Object item, boolean empty) {
if (item == getItem())
return;
super.updateItem(item, empty);
if (item == null) {
super.setText(null);
super.setGraphic(null);
} else if (format != null) {
super.setText(format.format(item));
} else if (item instanceof Node) {
super.setText(null);
super.setGraphic((Node) item);
} else {
super.setText(item.toString());
super.setGraphic(null);
}
}

};

cell.setTextAlignment(alignment);

switch (alignment) {

case CENTER:
cell.setAlignment(Pos.CENTER);

break;

case RIGHT:
cell.setAlignment(Pos.CENTER_RIGHT);

break;

default:
152
cell.setAlignment(Pos.CENTER_LEFT);

break;

}

return cell;
}
}
Respectiv:
FormattedTableCellFactory<Person, String> xx = new FormattedTableCellFactory<>();
xx.setAlignment(TextAlignment.CENTER);
firstNameCol.setCellFactory(xx);
Beneficiile utilizrii CSS-urilor pentru a seta stilul unui tabel constau

n eficiena de timp i eficiena de memorie, uurina utilizrii i construirii
bibliotecilor pentru celule, uurina customizrii formatrii de afiare.
Utilizm CSS-ul pentru a seta culorile celulei:
Fiecare celul poate fi stilizat direct din CSS. Spre exemplu, dac
dorim s schimbm culoarea predefinit a background-ului fiecrei celule din TableView la alb, trebuie s utilizm urmtorul CSS
.table-cell {
-fx-padding: 3 3 3 3;
-fx-background-color: white;
}
Pentru a seta culorile unor celule selectate dintr-un TableView, la

albastru, vom folosi urmtorul CSS:
.table-cell:selected {
-fx-background-color: blue;
}
Pentru ca table-cell:selected s funcioneze trebuie s setm

cellSelectionEnabled la true.
Multe implementri de celul extind IndexedCell n loc de Cell.
Aceasta permite adugarea altor dou pseudoclase: odd si even. Cu acestea
putem obine colorarea alternat a liniilor prin intermediul unui CSS de
forma:
153
.table-row-cell:odd{
-fx-background-color:lightblue;
}
Ca surs bibliografic pentru acest articol am folosit documentaia free

a platformei Java SE8 si JavaFX, parte dintre exemple sunt originale, altele
adaptate. Le mulumesc colegilor mei pentru suport, asisten i feedback.
Va mulumesc vou cititorilor, pentru lectur i atept cu plcere, ca ntotdeauna, discuiile cu cei interesai de mai multe detalii.
Autor
Silviu Dumitrescu - Line Manager @ Accesa
Peter Lawrey
Lui Peter Lawrey i place s inspire dezvoltatorii pentru a-i mbunti

calitatea soluiilor lor, s-i proiecteze sistemele dup principiile simplitii i
performanei i s se bucure mai mult de munca lor, fiind creativi i inovatori.
El are un blog binecunoscut, Vanilla Java care atrage 120K accesri de
pagini pe lun, este al treilea pe StackOverflow.com pentru Java i al doilea
pentru concuren i este dezvoltator principal al proiectului OpenHFT, care
include suport pentru off heap memory, thread pinning i low latency persistence i IPC (doar 100 nano-secunde).
13
CHRONICLE MAP AND YAHOO
CLOUD SERVICE BENCHMARK
Yahoo Cloud Service Benchmark is a reasonably widely used benchmarking tool for testing key value stores for a significant number of key e.g
100 million, and a modest number of clients i.e. served from one machine.
In this article I look at how a test of 100 million * 1 KB key/values performed using Chronicle Map on a single machine with 128 GB memory, dual
IntelE5-2650 v2 @ 2.60GHz, and six Samsung 840 EVO SSDs.
The 1 KB value consists of ten fields of 100 byte Strings. For a more optimal solution, primitive numbers would be a better choice. While the SSDs
helped, the peak transfer rate was 700 MB/s which could be supported by
two SATA SSD drives.
These benchmarks were performed using the latest version at the time of
the report, Chronicle Map 2.0.6a-SNAPSHOT.
MICRO-SECOND WORLD
Something which confounds me when reading benchmarks about

key-value stores is that they start with the premise that performance is really
important. IMHO, about 90% of the time, performance is not the most
important feature, provided you have sufficient performance.
These benchmark reports then continue to report times in milli-seconds,
not micro-seconds and throughputs in the tens of thousands instead of the hundreds of thousands or millions. If performance really was that important,
they would have built their products around performance, instead of the useful featuresthey do support, like multi-key transactionality, quorum updates
156
and other features Chronicle Map doesnt support, for performance reasons.
So how would a key-store built for performance look with YCSB?
THROUGHPUT MEASURES
The 50/50 tests 50% random reads and 50% random writes, the 95/5
tests 95% reads to 5% writes. It is expected that writes will be more expensive, and a higher percentage of reads results in higher throughputs.
Threads
50/50 read/update
95/5 read/update
339 K/s
910 K/s
1
2
122 K/s
235 K/s
262 K/s
496 K/s
565 K/s
1.010 M/s
30
816 K/s
1.787 M/s
15
973 K/s
1.445 M/s
LATENCIES
The following latencies are in micro-seconds, not milli-seconds.
Threads: 8
average
95th
99th
worst
50/50 read
5.7 s
15 s
25 s
52 ms
95/5 read
4.9 s
13 s
30 s
52 ms
50/50 update
13 s
27 s
44 s
52 ms
95/5 update
12.9 s
25 s
47 s
52 ms
Note: the benchmark is not designed to be GC free and creates some

garbage. This is not particularly high and the benchmark itself uses only
about 1/4 of CPU according to flight simulator, however it does impact the
worst latencies.
157
CONCLUSION
Make sure the key-value store has the features you need, but if performance is critical, look for a solution designed for performance as this can be
100x faster than full featured products.
OTHER HIGH PERFORMANCE EXAMPLES
Aerospike benchmark - Single server benchmark with over 1 M TPS,
sub-micro-second latencies. Uses smaller 100 byte records.
NuoDB benchmark - Supports transactions across a quorum. 24 nodes
for 1 M TPS.
Oracle NoSQL benchmark - A couple of years old, uses a lot of threads,
otherwise a good result.
VoltDB benchmark - Not tested to 1 M TPS, but promising. Latencies
around 1-2 ms, report has 99th percentile latencies which others dont include.
ROOM FOR IMPROVEMENT
MongoDB driver benchmark- Has 1000s of micro-seconds instead of
milli-seconds.
Cassandra, HBase, Redis- Shows you can get 1 million TPS if you use
enough servers, 288 nodes for 1 M TPS.
Report including Elasticsearch - Report includes runtime in a resource
Austere Environment
Hyperdex - Cover throughput only.
WhiteDB - Reports latencies in micro-seconds for 170 K records, and
modest throughputs.
Benchmark including Aerospace - Reports
158
FOOTNOTE
Using smaller values helps, and we suggest trying to make values closer to
100 bytes. This is the result of the 95/5 workload B, using 10x10 byte fields,
and 50 M entries as the Aerospike benchmark does. (30 clients)
[OVERALL], RunTime(ms), 60,669
[OVERALL], Throughput(ops/sec), 3,296,576
[READ], Operations, 190002671
[READ], AverageLatency(us), 4.81
[READ], MinLatency(us), 0
[READ], MaxLatency(us), 74864
[READ], 95thPercentileLatency(ms), 0.009
[READ], 99thPercentileLatency(ms), 0.014
[READ], Return=0, 115841209
[READ], Return=1, 74161462
[UPDATE], Operations, 9997309
[UPDATE], AverageLatency(us), 12.23
[UPDATE], MinLatency(us), 1
[UPDATE], MaxLatency(us), 75015
[UPDATE], 95thPercentileLatency(ms), 0.017
[UPDATE], 99thPercentileLatency(ms), 0.028
[UPDATE], Return=0, 9997309
Autor
Peter Lawrey - CEO @ Higher Frequency Trading
159
Victor Ionescu
Victor este un consultant IT care lucreaz n industria de dezvoltare

SAP. Prima sa ntlnire cu lumea SAP a avut loc aproximativ acum 3 ani i
jumtate, cnd a decis s ncerce acest domeniu, care la acea vreme i era complet necunoscut. De atunci, el a fost implicat n mai multe proiecte de dezvoltare SAP, asumndu-i o gam larg de sarcini care acoper ntregul ciclu
de dezvoltare software, de la consilierea clienilor i specificaia funcional a
produsului, pn la design tehnic i implementare.
n afar de aceste activiti legate de proiecte, Victor a i scris mai multe
articole cu privire la produsele i tehnologia SAP i a susinut cursuri de dezvoltaresoftware ABAP SAP pentru studenii de la Informatic din Cluj-Napoca. n timpul su liber, i place s analizeze pieele financiare, aceasta
reprezentnd de asemenea un domeniu n a crui cercetare este implicat n
mod activ la Universitatea Tehnic din Cluj-Napoca.
14
TENDINE N DEZVOLTAREA DE
SOLUII ENTERPRISE
n domeniul software, termenul enterprise a fost folosit ntotdeauna asociat ideii de complexitate. Prin definiie, o soluie enterprise trebuie s ofere
un spectru larg de funcionaliti, s fie configurabil pn la ultimul detaliu,
s fac fa n condiii de utilizare masiv i s aib multe alte caracteristici similare, ce fac ca n mod inevitabil astfel de soluii s devin un soi de
aplicaii-mamut, care tiu s fac orice, mai puin s fie intuitive i uor de
utilizat.
Dar studiile au artat c, dei multitudinea de funcionaliti este adesea
considerat esenial, n realitate scenariile complexe reprezint mai puin
de 20% din volumul de munc tipic al unui utilizator de software enterprise.
Prin urmare e de ateptat ca aceast situaie s se schimbe n viitor, din ce n
ce mai muli clieni declarnd c uurina n utilizare a software-ului are un
rol cel puin la fel de important cu multitudinea de funcii pe care acesta le
aduce.
O cauz a acestei schimbri de mentalitate este probabil i discrepana
foarte mare dintre aplicaiile pe care le folosim n viaa personal (vezi aplicaiile Google, Facebook, Twitter etc. ), i experiena enterprise, marcat n
primul rnd de interfeele complexe i implicit de o curb de nvare mult
prea lin.
Ca dovad a faptului c aceast necesitate este ct se poate de real, putem
lua exemplul [1] companiei de cosmetice Avon. Aceasta a fost nevoit s
stopeze n anul 2013 implementarea unei noi soluii de gestiune a comenzilor este vorba de un proiect cu o valoare de 125 milioane USD- datorit
faptului c angajaii au nceput s demisioneze , considernd c noua soluie
este prea dificil de utilizat i le ngreuneaz munca de zi cu zi.
Alt indicator al schimbrii sunt diversele iniiative implementate de ctre
companii, iniiative precum BYOD (Bring your own device) [2], prin care
162
se permite angajailor s foloseasc terminalele personale (telefon, tablet

etc.) n interes de serviciu. Aceast iniiativ merge mn n mn cu ideea
de mobilitate. De asemenea, un trend pe care companiile mizeaz din ce n
ce mai mult din dorina de a eficientiza procesele interne, facilitnd accesul
angajailor la resursele interne ale companiei, indiferent unde s-ar afla acetia.
Prin urmare, este evident faptul c i soluiile enterprise trebuie regndite,
astfel nct s in pasul cu noile trenduri, oferind utilizatorilor un alt fel de
experien, prin aplicaii simple i intuitive. ns tranziia ctre o astfel de
experien nu este una care s poat fi fcut cu uurin, pentru asta fiind
necesar o schimbare fundamental a modului n care aceste aplicaii sunt
concepute.
Un prim pas ar putea fi renunarea la genul de aplicaii-mamut, gndite pentru a acoperi ntregul spectru de funcionaliti, n favoarea unui set
de aplicaii, n care fiecare dintre acestea este conceput pentru un singur
Use-Case. Evident aplicaiile complexe nu pot s dispar ntru totul de pe
pia, n continuare existnd situaii (cei 20% menionai anterior) n care
este necesar un control mai amnunit asupra sistemului.
Pentru restul situaiilor ns pot fi dezvoltate astfel de mini-aplicaii, care
se remarc prin avantajul de a avea un scop foarte bine definit, putnd prin
urmare ghida utilizatorul ctre atingerea acestuia, prin interfee intuitive,
concepute special pentru acea situaie.
Pe lng uurina n utilizare, nu trebuie neglijat nici faptul c experiena
ne-a artat c, atunci cnd gndim la scar larga, cea de-a doua variant (N
funcii - N aplicaii) este mai uor de implementat, ntreinut i extins dect
varianta cu N funcii nglobate ntr-o singur aplicaie.
Prin astfel de demersuri practic putem spune c accentul se mut de pe
multitudinea pe functionaliti pe care o singur aplicaie le poate ndeplini,
pe capacitatea de integrare a multiplelor aplicaii.
ns adevrata provocare ine de modul n care poate fi fcut din punct
de vedere tehnic aceast tranziie, astfel nct soluiile business care i-au dovedit capacitatea n mediul productiv s poat fi folosite ca un nucleu al noii
generaii de software enterprise. Aceasta se ntmpl fiindc n lumea real
clienii sunt adesea refractari atunci cnd vine vorba de nlocuirea complet
a soluiilor existente cu unele noi. [3]
Iar n aceste situaii de cele mai multe ori gap-ul tehnologic dintre sistemele legacy ale clienilor i ceea ce numim State-of-the Art n materie de
163
Fig. 1 O nou paradigm de dezvoltare a aplicaiilor enterprise: de la N funcii - 1

aplicaie, la N funcii - N aplicaii
User Experience este att de mare, nct este nevoie de o serie de artificii tehnice pentru a facilita orice fel de remprosptare a experienei utilizatorului.
n acest fel ar putea fi caracterizat n linii mari situaia n care se afl
soluiile enterprise la momentul de fa: un punct de cotitur, care trebuie
gestionat cu foarte mult atenie de ctre fiecare productor de astfel de soluii, orice pas greit n aceast privin putnd nsemna pierderea clienilor n
favoarea competitorilor care au reuit s profite mai bine de noile tehnologii.
n continuare, vom realiza un studiu de caz n care vom analiza modul n
care SAP, liderul global n ceea ce privete soluiile business enterprise, a tiut
s rspund noilor cerine din pia, prin definirea unor strategii de adopie
a tehnologiilor state-of-the-art.
SAP se afl printre companiile care au reuit s identifice (sau chiar s
preconizeze) aceste tendine n urm cu civa ani, putnd astfel s pregteasc din timp terenul pentru schimbrile ce vor urma.
n 2013, SAP a pus la punct o strategie de User Experience [4] ce are la
baz trei mari piloni:
NEW: Dezvoltarea tuturor noilor aplicaii respectnd noile norme de
usability.
RENEW: mprosptarea experienei aplicaiilor existente prin interfee noi.
ENABLE: Sporirea posibilitilor de extindere ale aplicaiilor ce stau
la dispoziia clientului.
Aceast strategie specific tipurile de tehnologii care trebuie folosite n
funcie de context i care sunt regulile ce trebuie respectate n dezvoltarea
164
aplicaiilor.
n continuare, din multitudinea de soluii tehnice menionate n cadrul
strategiei de dezvoltare SAP vom aminti cteva, care vin s soluioneze tocmai problemele semnalate n prima parte a acestui articol: SAP Fiori, UI5 &
Netweaver Gateway.
La origine, SAP Fiori a fost numele dat unui val de noi aplicaii concepute pentru a acoperi cele mai frecvente Use Case-uri ntlnite n practic.
Specific acestor aplicaii sunt interfeele intuitive, toate construite dup acelai tipar, cu ajutorul framework-ului JavaScript SAP UI5. Acesta la rndul
su poate fi privit ca o extensie a popularului framework JavaScript JQuery,
ce aduce n plus o serie de funcionaliti specifice SAP.
Datorit succesului acestor aplicaii, SAP a decis s dea posibilitatea oricrui dezvoltator ter de a implementa propriile aplicaii Fiori. Astfel conceptul SAP Fiori a fost generalizat, aa nct n momentul de fa acesta nu
mai reprezint valul iniial de aplicaii al SAP-ului, ci mai degrab o serie
de principii de dezvoltare comune ce trebuie respectate atunci cnd vine vorba de implementare de noi aplicaii Fiori: role-based, responsive, simple,
coherent, delightful [5]
Pe scurt, aplicaiile Fiori ofer utilizatorului o experien mbuntit,
adaptat la nevoile acestuia (personalizat n funcie de rolul utilizatorului n
cadrul organizaiei), prin interfee simple & intuitive, indiferent de dispozitivul prin intermediul cruia acestea sunt accesate.
Dar dup cum am menionat deja, metodologiile i tehnologia pe baza
crora sunt construite noile aplicaii nu reprezint dect jumtate din poveste. Cealalt jumtate se refer la modul n care aplicaiile pot fi integrate
pentru a premite reutilizarea funcionalitilor deja existente.
i n cazul SAP aceast problem este cu att mai apstoare, cu ct n
portfoliul companiei se afl o mulime de soluii business consacrate, care
ns au fost dezvoltate n urm cu mai muli ani, chiar naintea erei Web 2.0.
Aici intervine rolul componentei SAP Netweaver Gateway, conceput
pentru a facilita integrarea dintre interfeele de ultim generaie (v. SAP Fiori) i backend-ul SAP. Practic Netweaver Gateway vine cu un set de adaptere
pentru diferitele tipuri de tehnologii care pot fi regsite n backend-ul SAP, i
permite expunerea acestor funcionaliti sub forma unor servicii REST care
pot fi consumate de ctre orice client SAP sau non-SAP.
n ceea ce privete protocolul de comunicare folosit pentru aceste servicii,
SAP a ales OData, un protocol open, specificat iniial de ctre Microsoft [6],
165
ce reutilizeaz verbele HTTP (GET, POST..) pentru accesul la entitile

serviciilor REST. Astfel se obine un landscape de sisteme n care ntreaga
comunicare poate avea loc pe baza unui protocol de comunicare unic, pe
nelesul tuturor entitilor implicate.
Analiznd ntreaga strategie de dezvoltare a SAP, ceea ce se observ n
primul rnd este deschiderea ctre tehnologii i standarde open, fapt ntlnit
mai rar pn acum n trecutul companiei, i care sugereaz c SAP a ales s
mizeze i pe comunitatea de developeri non-SAP pentru dezvoltarea viitoare
a produselor sale.
Ce putem ns spune fr reineri este c n cazul SAP combinaia acestor
tehnologii s-a dovedit a fi una ctigtoare, feedback-ul din rndul clienilor
vizavi de noile aplicaii Fiori fiind unul extrem de pozitiv. Pe de alt parte,
privit n ansamblu, aceast pia a aplicaiilor enterprise consumer-grade
nc poate fi considerat una emergent, dar cu un potenial de cretere fabulos, care ateapt s fie exploatat.
Bibliografie
1. 1. Wall Street Journal, Avon to Halt Rollout of New Order Management System, - http://online.wsj.com/articles/SB10001424052702303932504579251941
619018078.
2. 2. Forrester Consulting, Key Strategies To Capture And Measure The Value Of
Consumerization Of IT, - http://www.trendmicro.com/cloud-content/us/pdfs/
business/white-papers/wp_forrester_measure-value-of-consumerization.pdf.
3. 3. Forbes, Time To Reset Enterprise Softwares Future And Focus On Business
Value First, - http://www.forbes.com/sites/louiscolumbus/2014/03/26/time-toreset-enterprise-softwares-future-and-focus-on-business-value-first/.
4. 4. SAP, SAP User Experience Strategy, - http://www.sapdesignguild.org/User_
Experience_Strategy_2013_10.pdf.
5. 5. SAP, Fiori Guidelines, - http://experience.sap.com/fiori-guidelines/.
6. 6. OData Protocol Specification, - www.odata.org
Autor

Victor Ionescu - Senior IT Consultant, SAP Development

@msg systems Romania
Simona Bonghez, Ph.D.
Cu o pregtire teoretic i experien practic temeinice n Management

(expertiz n Managementul schimbrii, Managementul proceselor, Design
Organizaional, Management strategic i planificare de afaceri), Simona a
realizat numeroase programe de instruire i perfecionare n acest domeniu (inclusiv dezvoltarea materialelor suport), completate cu servicii de consultan (Analiza situaiei existente, dezvoltarea afacerii, realizare plan afaceri, management al proiectelor de trasformare si repoziionare radical) n
Romnia, Moldova, Republica Ceh, Slovacia i Austria.
Experiena de peste 20 ani n Management de proiect (trei certificri
internaionale n management de proiect oferite de Project Management
Institute, International Project Management Association i UK Office for
Government Commerce), dublat de experiena de peste 12 ani n instruirea
adulilor i livrare de traininguri de management de proiect, reprezint un
avantaj personal al Simonei.
Are un doctorat n sociologie i este, de asemenea, trainer acreditat SDI
(Strenght Deployment Inventory).
15
ESTUL NTLNETE VESTUL
INTELIGENA CULTURAL
N PROIECTE
CULTURA N CONTEXTUL
MANAGEMENTULUI DE PROIECT
Globalizarea are un impact major asupra modului n care companiile i
desfoar afacerile, acest lucru fiind reflectat, de asemenea, n modul n care
i gestioneaz proiectele. Mediul internaional ndeamn spre o mentalitate
diferit, una care nelege i accept diversitatea cultural ca un fapt n cadrul
proiectele noastre. Avnd echipe de proiect multi-disciplinare, multiculturale
care i desfoar activitatea la nivel transfrontalier, peste fusuri orare, precum i n mai multe limbi i culturi, crete i complexitatea procesului de management de proiect. Dincolo de presiunea de a realiza tripla constrngere
(satisfacerea cerinelor n timpul estimat i n condiiile de cost acceptate de
client) cerinele de calitate, asigurarea unei bune gestionri a echipei de proiect, asigurarea comunicrii pe ntreg ciclul de via al proiectului, diminuarea riscurilor, precum i echilibrarea nevoilor i ateptrilor prilor interesate
(al stakeholderilor), globalizarea a adus noi provocri cu privire la cultura i
diversitatea cu care managerii de proiect trebuie s se confrunte. Diferenele
lingvistice pot crea confuzii n ceea ce privete sarcinile i ateptrile proiectului. Dei limba englez a devenit o limb de circulaie internaional, nu
toate persoanele care lucreaz ntr-un proiect internaional sunt la acelai
nivel de fluen, dificultatea de a nelege sau a traduce exact termenii i conceptele este aplicabil att verbal, precum i n scris. Lucrul cu parteneri din
zone cu fus orar diferit creeaz probleme n sincronizarea membrilor echipei
168
i n asigurarea prezenei acestora la edine, unora dintre ei impunndu-li-se

s participe la conferine care se desfoar noaptea sau dimineaa devreme.
Exist i multe alte exemple, mai ales atunci cnd asemenea provocri au
legtur cu sponsorul proiectului sau clientul.
Una dintre cele mai mari provocri provine din diferenele culturale. Cultura este un sistem complex de componente interdependente care trebuie
s fie interpretate holistic (Moran et al., 2014, p. 12) care acoper valorile i
credinele, influennd conceptele oamenilor despre lumea nconjurtoare,
n general despre practicile de afaceri i n special, practicile cu privire la managementul de proiect (Stawicki, 2008). Avnd n vedere impactul ridicat
al culturii asupra modului n care ne desfurm activitatea n proiecte, n
special n mediul multicultural, literatura de specialitate conine modele cu
ajutorul crora diferenele culturale pot fi explicate i descrise. n acest sens,
cele mai relevante sunt lucrrile lui Richard E. Lewis, Edward T. Hall, Geert
Hofstede, i ale proiectului GLOBE, care ofer metode complementare de
a analiza cultura.

ntre 1967 i 1973, Geert Hofstede a realizat unul dintre de cele
mai cuprinztoare studii despre modul n care cultura influeneaz valorile
la locul de munc. Analiza lui a identificat iniial - patru grupe de valori
care disting culturile rilor unele de altele. Pn la sfritul anului 2010,
cercetarea iniial a fost extins n 93 de ri i alte trei grupe de valori au
fost adugate. Grupurile de valori sunt acum cunoscute ca dimensiuni ale lui
Hofstede privind cultura naional: Ecart al puterii (Distan fa de putere), Individualism versus colectivism, Masculinitate versus Feminitate, Evitare a incertitudinii, Orientare pe termen lung, Pragmatism versus Normativ
i Indulgen versus Reinere (www.geert-hofstede.com). Datele cercetrii
sunt disponibile pe site i pot fi fcute comparaii ntre ri, relevndu-se
astfel acele dimensiuni care avnd diferene mari de scor arat diferene
comportamentale care pot afecta dinamica echipei i ca urmare activitatea n
proiect.

Am ales s exemplific printr-o comparaie fcut pe site-ul menionat - ntre Romnia, Marea Britanie i Statele Unite ale Americii i voi
explica doar una dintre dimensiuni: Individualismul exprim msura n care
societatea ncurajeaz relaiile interpersonale i realizarea individual. O valoare sczut pentru individualism denot o societate cu o natur colectivist, membrii creia sunt responsabili unul pentru cellalt, cu legturi strnse
ntre ei. ntr-o societate cu un scor mare pentru aceast dimensiune (cum e
169
n cazul SUA) individul i poart singur de grij (i familiei apropiate), fr

s atepte sprijin (prea mult) din partea societii sau autoritilor. Ceea ce,
tradus n termeni de comportament n cadrul echipei spune c este foarte
plauzibil - n cazul n care avem colegi din SUA sau Marea Britanie ca
acetia s ncerce s rezolve problemele fr a cere sprijin, spre deosebire de
romni n cazul crora este mai probabil s apeleze la ajutorul colegilor, care
i vor sprijini simindu-se responsabili i pentru rezultatele lor.
Figura1: Comparaie ntre dimensiuni culturale (www.geert-hostede.com)
Cercetarea lui Hofstede a fost extins prin studiul empiric realizat de

grupul GLOBE (Casa et al., 2004). Din motive conceptuale, GLOBE a
transformat cele cinci dimensiuni ale lui Hofstede n nou, validate de cei
17.000 de participani din 62 de ri. Aceste ri au fost mprite de ctre
cercettori GLOBE n grupuri regionale pentru care au fost analizate asemnri i diferene culturale, dezvoltndu-se generalizri semnificative:
Un alt model ce merit s fie luat n considerare este modelul lui Lewis Clasele culturale - care a fost dezvoltat ca o soluie practic, vizual i
eficace pentru a ajuta companiile i alte organizaii internaionale s neleag cauzele i consecinele diferitelor dinamici culturale din ntreaga lume i
modul n care acestea au un impact asupra eficienei i profitabilitii afacerilor (www.riversdown.com). Richard D.Lewis a clasificat culturile lumii
n trei grupe:
Cultura Linear-Activ - Orientat ctre sarcini, planificatori extrem
de organizai,
170
Cultura Multi-Activ - Orientat spre oameni, volubili i relaionali,

Cultura Reactiv - Introvertit, orientat spre respect.
Figura 2: Modelul lui Lewis Clasele culturale (www.riversdown.com)
Modelul Lewis include toate elementele majore ale culturii, ele putnd fi
folosite de ctre managerii de proiect sau de membrii echipei de proiect pentru a nelege mai bine i pentru gestiona diferitele naionaliti i grupuri
etnice existente n echipele lor.
ntr-unul dintre interviurile luate, managerul de proiect (peste 15 ani
experien n context multicultural) ne-a dat exemplul unei echipe n care
membrii echipei erau romni, germani, englezi iar clientul arab. Cea mai
important dintre provocri a aprut odat cu comunicarea, dar nu numai
din cauza limbii. Limba englez este vorbit de obicei n lumea afacerilor
din Orientul Mijlociu. Cu toate acestea, contextul de comunicare este cu
mult diferit. Cuvintele comunicate n Occident sunt destinate pentru ceea
ce sunt i rspunsurile sunt furnizate ca suport pentru ceea ce a fost spus sau
scris; n lumea arab, este opusul. Comunicarea trebuie s fie interpretat
iterativ pentru a nelege lucrurile nespuse i trebuie citit printre rnduri.
Este tipic pentru arabi s suprainterpreteze ceea ce se comunic de ctre
omologii lor occidentali i pentru occidentali de a subinterpreta ceea ce este
comunicat de ctre omologii lor arabi. Pentru a simplifica i mai mult, o co-
171
municare ntre arabi i occidentali s-ar termina cu uurin cu reflecia arab,

Ce nseamn de fapt afirmaiile lor?, n timp ce occidentalii ar cugeta De
ce nu au rspuns la toate ntrebrile noastre?. Lecia nvat de managerul
de proiect respectiv a fost ca din start s aloce mult mai mult timp comunicrii, construirii unei relaii, fie cu un client, fie cu membrii echipei dac
sunt dintr-o ara arab.
Esena timpului este un alt element de luat n calcul n contextul managementului de proiect. Termenele stabilite pentru finalizarea livrabilelor pot
avea sensuri diferite, de exemplu, n Occident i n lumea arab. Managerul
de proiect intervievat ne ddea exemplu un proiect n care graficul de execuie spune c design-ul trebuie s fie finalizat pn la 1 noiembrie. n Vest,
termenul ar fi perceput nu mai trziu de 01 noiembrie, n lumea arab,
ns, ar putea fi n mod obinuit interpretat ca fiind n jur de 01 noiembrie,
n unele contexte poate nsemna chiar c activitatea ncepe la 1 noiembrie.
Un alt manager de proiect naionalitate german, 3 ani de experien, n
primul su proiect care a implicat membri de echip arabi - a mrturisit c
a fost surprins cnd a solicitat programul pentru vacan i nu a primit date
concrete, ci o sptmn dup sfritul Ramadanului. A fost imposibil pentru el s neleag c sfritul Ramadanului nu este o dat fix i
a petrecut
mult timp s caute pe internet o dat clar, specific, pn cnd a neles i
a acceptat c timpul are un flux diferit pentru unii membrii din echipa lui.
Unul dintre motivele pentru care foarte multe echipe se lupt cu tensiuni
ntre membrii si este acela c diferenele de gndire sunt ignorate. Contientizarea echipei privind aceste aspecte, imediat dup lansarea proiectului,
ncurajnd membrii ei s mprteasc din modul lor specific de gndire i
comportament, creeaz un context propice colaborrii.
INTELIGENA CULTURAL I COMPETENE

INTERCULTURALE. STEREOTIPURI.
Inteligena Cultural (IC) este definit ca fiind capacitatea unei persoane de a funciona i de a gestiona situaii n mod eficient n diverse setri
culturale (Ang & Van Dyne, 2008, p.8). IC este similar cu IQ i coeficientul
de inteligen emoional, deoarece cuantific un set de capabiliti importante att pentru succesul personal ct i profesional; unicitatea sa este dat
de faptul c se concentreaz n special pe competenele necesare pentru a fi
172
de succes n culturile necunoscute. Transferat n domeniul managementului

de proiect, inteligena cultural este capacitatea de a manifesta competenele
interculturale n cadrul echipei de proiect multi-culturale prin adaptabilitate
i cunoatere.
Proiectul GLOBE a identificat - n acest context intercultural - 22 de
atribute de leadership apreciate n mod global, caracteristici care faciliteaz
conducerea echipelor, precum i acele atribute care sunt vzute ca obstacole
pentru un leadership eficient, caracteristici care mpiedic efectiv conducerea
eficient a echipelor.
Valued Leadership Attributes
Trustworthy
Just
Encouraging
Obstacles to Effective
Leadership
Loner
Foresight
Plans ahead
Motive arouser
Confidence builder
Motivational
Effective Bargainer
Win-win problem
solver
Communicative
Team builder
Coordinator
Noncooperative
Excellence oriented
Honest
Egocentric
Positive
Intelligent
Administrative
skilled
Dynamic
Decisive
Irritable
Dependable
Ruthless
Informed
Nonexplicit
Asocial
Dictatorial
Tabelul 1: Atribute pozitive i negative ale liderilor (Northouse, 2007, p.322-323)
Competenele interculturale au mai multe faete aa cum este evideniat

n figura de mai jos. Informaiile au fost obinute n urma unor sondaje prin
telefon de la persoanele responsabile pentru deciziile de angajare din companii din sectorul public, sectorul privat i ONG-uri care lucreaz n context
multicultural; baza: global (n = 367).
Orice persoan are o inteligen cultural specific (IC). Acesta poate fi
evaluat i mbuntit ca parte a nvrii interculturale. Nu este uor, nici
simplu - a declarat unul dintre analitii de business intervievat (de naionalitate romn, peste 5 ani de experien n proiecte globale) nu este ca i
cum ai decide ntre o stngere de mn i o plecciune sau a purta un vl sau
nu, nseamn s fii capabil s analizezi nenelegerile i s le corectezi, sau
s le poi evita de la nceput. Unul dintre managerii de proiect intervievai
Figura 3: Cum definesc angajatorii competenele interculturale

(http://infogr.am/intercultural-skills?src=web)
173
a folosit un cuvnt interesant cnd a fost ntrebat despre abilitile interculturale: Worldmindedness. El s-a referit la o contientizare global a altor
culturi i oameni, trstur care poate fi nvat. Potrivit Merryfield et al,
worldmindedness, de multe ori ncepe ca o contientizare la nivel global i
crete n momentul n care persoanele ncep s aprecieze punctele de vedere,
experienele i viziunile asupra lumii ale celorlali, n special cele destul de
diferite de ale lor (Merryfield et al, 2008). Parafrazndu-l pe Merryfield,
din perspectiva managerului de proiect, fiind worldminded nseamn c
acesta a dobndit obiceiul de a gndi despre efectele deciziilor sale asupra
tuturor stakeholder-ilor din proiect, avnd n vedere consecinele deciziilor
din proiect dintr-o perspectiv mai larg. De asemenea, fiind un manager de
proiect worldminded nseamn c el sau ea ncep s utilizeze noi pentru a
se referi nu numai la membrii echipei, dar i la parteneri, la clieni, furnizori,
utilizatori. Managerul de proiect cu peste 20 de ani experien n proiecte
complexe, a considerat implicarea n echipe multi-culturale ca fiind o oportunitate pentru educaie i dezvoltare cultural. El a menionat, de asemenea,
creativitatea ca fiind o abilitate necesar n gsirea de modaliti acceptabile
i eficiente de a motiva membrii echipei care provin din medii culturale diferite.
174
CONCLUZII
Globalizarea este un proces complex cu faete multiple, iar impactul ei
asupra abilitilor cerute managerilor de proiect i membrilor echipelor de
proiect este din ce n ce mai pregnant. Se pare c mai degrab dect s unifice
lumea, globalizarea divizeaz culturile, construind un mediu internaional,
multicultural n aproape orice proiect, reclamnd o stare de spirit diferit, una
care nelege i accept diversitatea cultural ca un fapt, ca un context pentru
proiectele noastre. n aceste condiii cresc din ce n ce mai mult - cerinele
privind competenele celor implicai n proiecte. Pentru a sprijini managerii
de proiect n gestionarea noilor situaii cu care sunt confruntai, pentru a-i
ajuta s fac fa diferenelor culturale n mod eficient, un prim pas este
creterea gradul de contientizare: nelegerea conceptului de cultur, a caracteristicilor acesteia i a efectelor ei asupra dinamicii echipei de proiect i a
alegerii cilor optime de a gestiona proiectul.
REFERINE
1. Ang, S., Van Dyne, L. (2008), Handbook of Cultural Intelligence: Theory, Measurement, and Applications. www.culturalq.comds ,3
2. Hofstede, G. (1999), Cultures Consequences:International Differences in Work-related
Values, Sage Publications, Thousand Oaks, CA
3. Hofstede, G, Hofstede, G.J., Minkov, M. (2010), Cultures and Organizations: Software for the Mind. Intercultural Cooperation and Its Importance for Survival, McGraw
Hill, US.
4. Merryfield, M.M., Lo, J. T-Y., Po, S.C., Kasai, M., (2008), Journal of Curriculum
and Instructions, January 2008, vol.2, no.1.
5. Moran, R.T, Harris, Ph.R., Moran, S.V., (2012), Managing Cultural Differences:
Global Leadership Strategies for Cross-Cultural Business Success, Eighth Edition, Elsevier Inc, UK
6. Northouse, P. G. (2007). Leadership: Theory and Practice. 4th ed., Sage Publications,
Thousand Oaks, CA
7. http://geert-hofstede.com/dimensions.html visited on July 24, 2014
8. http://www.tlu.ee/~sirvir/IKM/Leadership%20Dimensions/globe_project.html
visited on July 24, 2014
9. http://www.riversdown.com/cross-culture/the-lewis-model/ visited on July 24,
2014
10. http://www.nafsa.org/_/file/_/theory_connections_adjustment.pdf visited on August 20, 2014
175
Autor
Simona Bonghez, Ph.D. Managing Partner @ Colors in Projects
Dan Suciu, Ph. D.
Dan Suciu este lector la Facultatea de Matematic i Informatic a Universitii Babe-Bolyai unde susine att cursuri tehnice de baz (Baze de
date, Gestiunea tranzaciilor i baze de date distribuite) ct i cursuri dedicate
metodologiilor de dezvoltare i coordonare a proiectelor software (Gestiunea
proiectelor software, Analiza i gestiunea sistemelor informatice complexe).
De mai bine de 5 ani de zile colaboreaz cu compania 3Pillar Global unde
a avut ocazia s aplice n practic o mare parte din elementele ce compun
cursurile sale. La 3Pillar ocup n prezent poziia de Director of Technical
Training.
n viaa personal este un mare consumator de filme de animaie i jocuri
video.
16
DESPRE ANGAJAMENTE
N PROIECTE AGILE
Sunt contient c titlul este din start unul care poate s agite spiritele.
Aceasta deoarece auzim de multe ori c n Agile ideea de angajament (commitment) este depit, lsnd loc altor termeni ce exprim mai bine rezultatul colaborrii continue ntre client i echipa de proiect pentru implementare
produsului dorit. Acest lucru nu a rmas doar la nivelul de idee. n 2011
s-au adus cteva modificri importante ghidului Scrum care se bucur la
ora actual de prestigiul de a fi una dintre cele mai populare metodologii
Agile. Una dintre aceste modificri const n nlocuirea integral a cuvntului commitment cu o alternativ mai puin dur cum este cea de predicie sau
prognoz (forecast).
UNII LUCREAZ, ALII PLTESC

Nu doar denumirea care ne este propus spre utilizare are o nuan mai
puin rigid, dar i mentalitatea sugerat este una diferit. Nu ne mai concentrm pe cnd se pot livra anumite funcionaliti ci pe ce funcionaliti se pot livra ntr-un interval (de obicei scurt) de timp.
Pe de alt parte ns, orice potenial client are un plan, o perioad de timp
n care trebuie s pun n aplicare acel plan precum i o sum de bani maxim (buget) pe care o poate cheltui n acest scop. Cu alte cuvinte are nite
obiective foarte precise. Decizia pe care o ia n alegerea unei companii care s
i implementeze o soluie depinde ntr-o foarte mare msur de capacitatea
acesteia de a se ncadra n constrngeri i de a ndeplini aceste obiective.
178
Ca lucrurile s fie i mai complicate, experiena ne arat c muli dintre

clieni sunt departe de a avea o idee clar cu privire la soluia software ce urmeaz s fie implementat. Cu toate acestea, ei au nevoie de un angajament
i n absena acestuia vor renuna uor la cei care enun termene de livrare
vagi.
Cu alte cuvinte estimrile i prediciile se afl n responsabilitatea celor
care dezvolt o soluie software n timp ce obiectivele n mod natural sunt
stabilite de ctre cei care pltesc pentru soluia software. Angajamentul, n
acest context, este rezultatul unei negocieri i l reprezint nelegerea sau
contractul dintre cei care pltesc i cei care realizeaz munca ntr-un proiect.
CARE E PROBLEMA CU ANGAJAMENTUL?
Exist o serie de argumente pro i contra angajamentului n Agile. Voi
enumera cteva din cele care privesc angajamentul ca fiind nociv ntr-un
mediu agil.
n primul rnd se creeaz o relaie de parteneriat ntre cele dou entiti
aminitite mai sus (echipa de dezvoltare a proiectului i clientul care pltete
munca de dezvoltare) care din start tiu c:
cerinele enunate nu sunt neaprat complete, corecte i finale;
estimrile care se pot face au un grad ridicat de incertitudine;
probabilitatea ca echipa de dezvoltare s-i schimbe n timp configuraia este foarte ridicat.
Oricare dintre pri ar trebui s se fereasc de orice angajament n aceste
condiii, tiind din start c probabilitatea de a fi nclcat este foarte mare.
Totui angajamentul este necesar nceperii unui parteneriat (n marea majoritate a cazurilor) i negocierea asupra angajamentului va continua pe tot
parcursul derulrii proiectului.
Este evident c orice echip i poate lua un angajament pe rezultatul propriilor estimri i predicii, dar probabilitatea de respectare a acestuia nu va fi
cu nimic mai ridicat dect n cazul unui proiect waterfall clasic. Acest lucru
aduce frustrri n ambele pri fcnd ca echipa de dezvoltare s fie tentat s
declare c Agile nu e cu nimic mai bun ca waterfall, n timp ce clientul trece
rapid peste faptul c, probabil, calitatea a ceea ce a primit este mai mare i
rmne cu senzaia c a primit mai puin dect ar fi trebuit.
Unul dintre lucrurile general valabile n psihologia uman este influena
exagerat a aspectelor negative. Iar contextul specific unui proiect software
179
face ca angajamentul s fie o surs constant de astfel de aspecte negative.

Desigur c angajamentul nu aduce doar probleme ntr-un context agil.
Printre altele, el responsabilizeaz echipa de dezvoltare i o ajut prin inducerea unui stres pozitiv s se concentreze mai eficient pe ceea ce are de fcut.
CUM E NATURAL S FIE?
Cu siguran aplicarea ntregii metodologii clasice de gestiune a
proiectelor n coordonarea proiectelor software a fost un proces inevitabil
dar artificial. Spun c a fost inevitabil pentru c la momentul respectiv nu se
ntrezreau att de evident caracteristicile specifice proiectelor software ce le
faceau incompatibile cu procesele riguroase i rigide ale managementului
clasic. Ulterior, valorile care au stat la baza apariiei ideii de dezvoltare agil a
softului, acele valori care au reprezentat esena manifestului Agile din 2001,
i-au avut rdcinile n observarea atent a acestor incompatibiliti.
Voi face apel la propria experien pentru a da cteva exemple de abordare
waterfall-like a proiectelor software. De obicei lucrurile urmau cu o frustrant
frecven urmtorul ablon: atunci cnd ceva nu mergea bine n proiect cineva
trebuia s i corecteze corespunztor comportamentul astfel nct procesul
s poat funciona. Dar comportamentul continua s se repete!
De exemplu, dac specificaiile erau incomplete sau neclare, clientul
trebuia s se strduiasc mai mult s ridice calitatea acestor specificaii. n
caz contrar, cum se atepta la un produs de calitate, dac cerinele sale nu
erau de calitate? Cu toate acestea, ntr-o etap ulterioar a colaborrii sau n
urmtorul proiect clientul greea din nou i specificaiile sale artau la fel
de prost.
Atunci cnd apreau pe parcursul derulrii unui proiect, modificri importante ale cerinelor iniiale, implementarea lor era amnat dup terminarea proiectului conform cerinelor iniiale sau erau adoptate imediat (la
insistenele clientului) dar cu o reconsiderare larg a termenului de livrare.
De fiecare dat ns scoteam n eviden riscurile ridicate ale unei astfel de
abordri i sugeram inhibarea oricror alte tendine de a umbla la specificaii. Cu toate acestea, solicitrile de modificare continuau s apar.
n fine, un alt exemplu clasic era cel al estimrilor de timp necesar pentru
implementarea a diverse funcionaliti, estimri care erau n mod repetat
greite. Chiar i o experien ridicat n implementarea unor task-uri similare
nu elimina complet erorile de estimare, obicei ce ducea la rezolvri empirice,
de genul adugrii unui timp suplimentar de 10% sau 20% din estimarea
180
iniial, pentru ca procesul s se deruleze n bune condiii.

Dup prerea mea, unul dintre cele mai importante lucruri pe care le-a
fcut manifestul Agile a fost acela de a nu considera nite comportamente
naturale n contextul proiectelor software ca fiind greeli. Iar consecina
a fost aceea c principiile Agile enunate au avut rolul de a considera aceste
obiceiuri ca implicite i au propus o schimbare de mentalitate i de abordare,
o adaptare a proceselor la situaia dat. Astfel avem principii ca : Deliver
working software frequently, Welcome changing requirements, even late in development, Working software is the primary measure of progress. Dar lum n
considerare i procese i practici noi ce ncurajeaz dezvoltarea iterativ (pe
principiul analizezi puin, implementezi puin, testezi puin i reiei ciclul)
sau estimarea colectiv. Toate acestea transform incapacitatea unui client de
a da specificaii clare i complete de la prima ncercare sau apetitul su pentru modificri de cerine precum i estimarea cu o acuratee sczut a timpului de dezvoltare n nite evenimente banale, de la sine nelese i acceptate.
Dar s revenim la tema noastr i anume angajamentul. Consider c practica clientului de a cere echipei de dezvoltare un angajament nu trebuie nici
pe departe privit ca ceva greit, nvechit sau ne-natural. Dimpotriv, este
perfect rezonabil ca el s cear i s se atepte la un angajament. Pasul pe care
ar trebui s-l facem este unul, cred eu, conform filozofiei Agile i anume acela de a ne adapta acestei realiti i de a gsi procesele sau practicile potrivite
pentru a anula dezvantajele angajamentului.
ANGAJAMENTUL N MANIERA AGILE
Voi exemplifica modul n care putem lucra cu predicii i angajamente
pe proiecte Agile considernd un proiect ce se afl n faza de estimare a implementrii task-urilor pentru iteraia a 8-a. Echipa de dezvoltare estimeaz
funcionalitile ce trebuie s fie dezvoltate ntr-o iteraie folosind puncte
de complexitate. S presupunem c graficul de mai jos reprezint numrul
de puncte de complexitate realizate de ctre echip pentru fiecare iteraie pe
durata celor apte iteraii care s-au derulat deja.
Considernd aceste valori i calculnd media punctelor realizate per iteraie obinem 12.42, putem s facem o predicie pentru iteraia a 8-a i
s spunem c vom acoperi 13 puncte de complexitate. Evident, constatnd
deviaiile n cazul iteraiilor precedente putem s propunem intervalul dintre 12 si 15 puncte de complexitate. Cu siguran ns c aceste valori nu
le putem folosi ca angajament. n primul rnd pentru c este vorba de un
181
interval, iar angajamentul va trebui s se refere la un numr clar de puncte pe

care ne propunem s le acoperim. Pe de alt parte din grafic rezult c doar
n aproximativ o jumtate din iteraii am reuit s facem peste 13 puncte de
complexitate, fapt ce face ca 13 s nu reprezinte nici pe departe un candidat
bun pentru luarea unui angajament.
Pe de alt parte observm c n 6 situaii din 7 am reuit s acoperim 10
puncte de complexitate. Prin urmare 10 reprezint o valoare mult mai bun
de a se constitui ntr-un angajament deoarece probabilitatea de nu-l ndeplini este foarte mic.
CONCLUZII
Scopul acestui articol a fost acela de a arta c a prefera un termen ca
predicia n detrimentul angajamentului nu reprezint o abordare n spiritul
valorilor Agile i c ambii termeni pot coexista cu succes n economia unui
proiect software. Faptul c echipele de dezvoltare se simt mai confortabil i
sunt mai capabile s fac i s lucreze cu predicii nu reprezint un argument
suficient pentru a ncerca s redefinim mentalitatea clientului i s-l convingem c nu are nevoie de angajamente. Mai mult, practica ne arat c un
istoric consistent de predicii ne poate duce la mbuntirea calitii angajamentului pe care trebuie s ni-l lum n faa clientului.
182
REFERINE
1. Bob Galen - The Agile Project Manager Whats the Big Deal about Commitment?,
MATRIX blog, 2012 (http://blog.matrixresources.com/blog/agile-project-manager-%E2%80%94-what%E2%80%99s-big-deal-about-commitment)
2. Scott Sehlhorst - Agile Estimation, Prediction, and Commitment, Tyner Blain
articles, 2011 (http://tynerblain.com/blog/2011/08/09/agile-estimation/)
3. John Clifford Agile Estimation:Key Principles and Practices for Successful Agile Projects, Construx presentation
Autor

Dan Suciu Ph. D.

- Director Technical Training @ 3Pillar Global
- Lector @ Facultatea de matematic, Universitatea Babe Bolyai
183
Monica Soare
Monica Soare are peste 15 ani de experien n managementul resurselor

umane n companii de top din domeniul FMCG i Farma, ultimii ani dedicndu-i consultanei. Monica are o abordare pragmatic, analitic, pasiune
i energie, precum i o experien vast n managementul unor proiecte mari
i diverse n domeniul resurselor umane.
Ariile de expertiz ale Monici includ: strategie de resurse umane, diagnoz organizaional, recrutare i employer branding, managementul talentelor, compensaii i beneficii, training, coaching, dezvoltarea angajailor,
schimbare organizaional i consultan.
Monica Soare are peste 15 ani de experien n managementul resurselor
umane n companii de top din domeniul FMCG i Farma, ultimii ani dedicndu-i consultanei. Monica are o abordare pragmatic, analitic, pasiune
i energie, precum i o experien vast n managementul unor proiecte mari
i diverse n domeniul resurselor umane.
17
MANAGEMENTUL
ECHIPELOR VIRTUALE
n 1999 gigantul NASA a lansat n spaiu un satelit orbitator, care la scurt
timp dup lansare a explodat. Aceast greeal aducnd prejudicii de peste
125 milioane $ Statelor Unite.
n urma anchetei s-a descoperit c la acest proiect lucra o echip virtual
cu mari probleme de comunicare. Una era localizat n California i cealalt
n Colorado. n mare parte, comunicarea dintre aceste dou echipe se fcea
prin mail, eund n a realiza c echipa din Colorado lucra cu uniti metrice
iar cea din California cu uniti imperiale.
Comitetul care a anchetat accidentul a descoperit c discuiile dintre cele
dou echipe erau mult prea informale i c ambele echipe triau cu impresia
c se neleg perfect.
Acest exemplu dateaz din 1999 pe cnd echipele virtuale erau la nceputuri ns i astzi, dup 15 ani, ne confruntm cu aceleai probleme, firete
gravitatea deosebind de la o industrie la alta.
Aprute prima dat n domeniul IT&C, echipele virtuale au crescut de
la o zi la alta, fiind eficiente din punct de vedere al costurilor pentru orice
companie i n aproape orice domeniu.
Recent, Economist Intelligence Unit, aripa de cercetare a editorialului
The Economist a realizat o cercetare asupra persoanelor care lucreaz n
echipele virtuale, oamenii care i conduc i provocrile cu care se confrunt.
Astfel, au descoperit c unul din trei manageri recunote c echipele virtuale sunt conduse defectuos datorit faptului c managerii aplic aceleai
practici de leadership precum n cazul echipelor clasice.
CT DE VIRTUALI SUNTEM DE FAPT?
Din ce n ce mai multe companii mbrieaz ideea echipelor virtuale
pentru reducerea costurilor sau pentru a crete flexibilitatea livrrii servicii-
186
lor, astfel, apariia echipelor virtuale a fost o stare natural care a aprut i s-a
dezvoltat pe zi ce trece tot mai mult.
Evoluie sau nu, echipele virtuale sunt prezente aproape n fiecare companie. Studiul realizat de Forbes la nceputul anului 2014, n rndul companiilor americane relata c n general, 30% din numrul total de angajai
lucreaz n echipe virtuale, n cretere fa de 2010 cnd acest procent era de
23%.
CUM ARAT O ECHIP VIRTUAL?
nfiarea ei, asemntoare cu cea a unei echipe clasice, are ntre 5 i 20
de oameni. Marea majoritate sunt project-based i membrii acestora fac parte
i din alte proiecte, n timp ce pentru alii este un full-time job i deloc surprinztor c majoritatea se afl n industria IT&C.
Membrii echipelor virtuale sunt omniprezeni i provin n mare parte din
Generaia Y. Din fericire, IT-ul a spart orice barier geografic i de timp,
elibernd oamenii s lucreze oricnd de oriunde i orice vor.
PROVOCRI
Echipele virtuale vin cu foarte multe provocri. n primul rnd colegii nu
se vd ntre ei, fapt ce mpiedic stabilirea unei relaii bazat pe ncredere.
Dac nu este gestionat corect, aceast lips de ncredere poate sabota toate
obiectivele pe care aceast echip le are.
O alt provocare major este comunicarea, n special atunci cnd n echipa virtual intr persoane din alte ri sau culturi. Comunicarea prin mail sau
telefon poate fi dificil, deoarece lipsete contactul vizual sau alte elemente
ale limbajului corporal.
Motivarea fiecrui membru n parte este un element greu de obinut precum i organizarea de edine, datorit diferenelor de fus orar.
Mai mult, soluionarea unui conflict este mult mai dificil. Amnarea rezolvrii conflictului se las de obicei cu prsirea echipei de ctre oamenii
cheie.
MOTIVELE EURII UNEI ECHIPE VIRTUALE
Muli manageri nu reuesc s creeze un mediu motivant de lucru la distan. Acest minus aflndu-se pe locul 2 n topul dificultilor gestionrii
unei echipe virtuale, dup diferenele culturale. n condiiile actuale, membrii unei echipe virtuale pot fi din localiti, ri sau continente diferite i
provocarea de a colabora nu este doar din partea managementului ci i a
187
membrilor.
Capcanele mediului virtual pot fi: ntrzierea feedback-ului, prejudeci,
interpretri greite ale e-mailurilor, care s-ar putea soluiona uor dac neam afla fa n fa la o discuie.
Dac facei parte dintr-o echip virtual multe din aceste probleme vi se
pot prea familiare.
CUM ARAT ECHIPA VIRTUAL DE SUCCES?
Echipele virtuale sunt separate de timp, cultur i atribute lingvistice.
Echipele virtuale globale sunt foarte uor de format i sunt foarte agile n
natura lor. Ele pot ajuta companiile s scad din timpii de rspuns n aceast
pia hiper-competitiv, tocmai profitnd de avantajul fusului orar i al echipei dispersate pe ntreg globul.
Pentru ca o echip virtual s aib succes, managerul trebuie s neleag
n primul rnd c echipa virtual este precum joaca ntre copii suprcioi
dintr-o grdini internaional.
Tocmai aici apare dificultatea managerului unei astfel de echipe.
Grdinia are foarte mare nevoie de aceti copii deoarece sunt motorul
de supravieuire al businessului. Copiii cu un background foarte diferit risc
s nu se neleag ntre ei i s se jigneasc constant fr a ajunge la consens,
dar educatoarea asemenea managerului trebuie s mpace pe toat lumea n
vederea dezvoltrii att a grdiniei ct i a copiilor.
Obiective clar definite, un set de reguli bine delimitat, membri angajai
proactiv n realizarea obiectivelor, dispui s mprteasc informaiile eseniale sunt cteva dintre ingredientele eseniale succesului echipelor virtuale. La fel de important este ca membrii unei astfel de echipe s aib abiliti
de comunicare foarte bune i s i ofere n mod constant feedback. Nu n
ultimul rnd o practic a echipelor virtuale de succes este cel puin o ntlnire
fa n fa a membrilor, mcar o dat pe an.
Dar pentru ca toate acestea s funcioneze, managerul echipei trebuie s
creeze un cadru propice comunicrii att formale ct i informale, a feedbackului i a nelegerii diferenelor impuse de spaiu i timp.
Ca urmare, am stabilit cinci direcii importante pe care managerul de
succes al unei echipe virtuale trebuie s le stpneasc i s le dezvolte:
188
1. COMUNICAREA
Comunicarea eficient este esenial ntr-o echip virtual. Deschiderea,
comunicarea onest nu doar c ne ajut la nlturarea nenelegerilor ci ne
crete eficiena.
Cnd vorbim de comunicare eficient, evident vorbim de ascultare activ
i de dorin de cooperare.
De asemenea, comunicarea nseamn i feedback care alturi de vetile
proaste se ofer cel mai bine ntre patru ochi. Cnd nu este posibil, ncercai
s folosii Skype, Video Chat-ul sau telefonul, n niciun caz e-mailul.
2. CULTURA
Diferenele culturale sunt tocmai valoarea adugat a echipelor virtuale
dar n acelai timp pot crea probleme.
O modalitate bun de abordare a diferenelor culturale este nvarea
ctor mai multe lucruri despre background-ul membrilor echipei. Acest fapt
implic o cercetare srguincioas din partea managerului care s pun n
valoare aceste diferene.
3. CONSTRUIREA RELAIILOR
Cnd faci parte dintr-o echip virtual trebuie s faci un efort suplimentar n ceea ce privete relaiile.
Meninerea ncrederii, deschiderea, rspunsul prompt la telefoane sau
e-mailuri este esenial. Un rspuns rapid le arat colegilor ti c i pas de
problemele lor. Ca manager, fii sensibil fa de colegii aflai n zone cu fus
orar diferit. Dac o ntlnire este stabilit prea trziu ine minte c unii vor fi
mai puin vocali i angrenai n discuii dect ceilali.
Folosete-te de uneltele pe care le ai la dispoziie. Folosete-te de Facebook sau LinkedIn pentru a vedea care este background-ul colegilor sau ce
preferine au. Apoi mcar o dat pe an ofer posibilitatea ca echipa ta s se
ntlneasc i fa n fa.
4. COOPEREAZ CU IZOLAREA
Profesionitii care lucreaz n echipe virtuale se confrunt de multe ori cu
sentimente de singurtate i izolare, care nu sunt deloc productive. Sunt persoane care datorit faptului c nu lucreaz n cldirea organizaiei vor simi
c nu fac partea din ea sau vor crede adeseori c nu sunt importani pentru
organizaie. Aceste situaii sunt i mai greu de combtut dac unele persoane
189
au fost implicate n procese decizionale.

Dac suntei managerii unei echipe virtuale, luai pai activi n combaterea
izolrii unor membri. Formai un grup online n care s se discute chestiuni
non-formale ntre membrii echipei. Un loc unde i pot trimite link-uri sau
s povesteasc pe scurt ce au fcut n weekend. Din punct de vedere tehnic
nu mai este o provocare ca membrii echipei s se conecteze virtual. Fii creativi i folosii-v instrumente care v stau la dispoziie fie ele i reele sociale.
5. ADAPTAREA
Secretul managerului virtual de succes st n abilitatea lui de a previziona
schimbrile proiectelor sau a pieei forei de munc virtual i de a se adapta
la schimbrile rapide care se produc n industrie i n echipa lui.
n urma unui studiu aplicat asupra mediului i al tendinelor de management n echipele virtuale am ajuns la 15 de tehnici pe care fiecare manager
virtual ar trebui s le aplice pentru a avea rezultate excelente n managementul echipei sale:
1. Recruteaz oamenii potrivii pentru echipa ta. n cazul unei echipe
virtuale fiecare persoan trebuie s fie precum o pies de puzzle, perfect mbinat cu cellalte. Contrabalanseaz lipsurile echipei virtuale
cu oameni care se potrivesc i care au abilitile de comunicare i inteligen emoional foarte bine dezvoltate.
2. Alege n echipa ta oameni care au mai lucrat n echipe virtuale sau
care au mai lucrat mpreun cu succes n alte proiecte.
3. Trateaz echipa virtual la fel ca pe o echip clasic ns acord atenie nzecit fiecrei discuii sau e-mail. La fel ca ntr-o companie,
membrii echipei sunt motivai s se dezvolte. O discuie periodic,
ntre patru ochi n care s se discute planul fiecruia de dezvoltare va
fi foarte bine primit. Oamenii vor simi c managerul este sensibil
fa de direcia n care doresc s se dezvolte i compania vrea s investeasc n ei.
4. Investete ntr-o platform online de comunicare interioar, asemntoare reelelor de socializare. De asemenea, nainte de fiecare
ntlnire pregtete agenda ns, las timp i pentru construirea
relaiilor. Datorit separrii fizice, o mare provocare a acestor echipe
este imposibilitatea de a nva unii despre ceilali lucruri eseniale i
despre rolul pe care fiecare l au n proiect.
5. Asigur-te c task-urile sunt semnificative pentru echip - n mod
190
ideal, misiunea echipei virtuale ar trebui s rezoneze cu valorile

fiecrui membru - att ca indivizi ct i ca profesioniti care vor s i
dezvolte abilitile cu importan vital pentru companie. Importana
muncii cu sens i a viziunii care inspir este foarte clar, aduce rezultate vizibile n echipele virtuale. Menionm n acest sens dou exemple foarte cunoscute: colaborarea care a produs enciclopedia online
Wikipedia i cea a creatorilor Linux, un sistem de operare cu surs
deschis. Nici una dintre acestea dou nu este o companie ns ambele sunt realizate de un numr mare de voluntari, majoritatea fiind
inspirai de devotamentul i de misiunea pe care o au.
6. Stabilete obiectivele echipei - Membrii echipei trebuie s tie i s
neleag de ce lucreaz ntr-o echip virtual i de ce sunt importani
pentru acea echip. Dac ei neleg doar rolul lor n proiect i nu impactul pentru echip, nu mai discutm de o echip virtual.
7. Stabilete regulile - Chiar i dac membrii echipei lucreaz de acas
sau din locaii diferite, ei trebuie s aib un set acceptat de reguli.
Regulile de baz includ setarea orelor n care este ateptat din partea
membrilor s lucreze, pauzele de mas, determinarea edinelor, care
sunt obligatorii pentru toi membrii.
8. Obine tehnologia necesar - Echipele virtuale exist de ceva vreme,
cu toate astea, trendul s-a accelerat n ultimii ani. Tehnologia sprijin
din plin echipele virtuale, incluznd - internetul, conferinele audio,
camere video sau folder-e comune. Caut cea mai bun tehnologie de
comunicare potrivit personalitii echipei tale.
9. Caut oportuniti de socializare - Echipele localizate mpreun au
oportunitatea de a socializa toat ziua. Echipele virtuale nu au aceast
oportunitate, aadar managerul trebuie s se concentreze pe stabilirea
de relaii. Ideal ar fi ca mcar o dat pe an, toat echipa s se ntlneasc pentru un team-building. n cazul n care nu este posibil, se
poate ncerca mcar pentru o perioad, s se grupeze cte doi membri
care s lucreze mpreun dintr-o locaie i rotativ, fiecare membru s
lucreze direct cu colegii si.
10. Politica task-urilor scurte - Nu delega proiecte foarte mari i lungi unei
echipe virtuale. Datorit dificultilor care pot aprea n comunicare
este irealist s te atepi ca echipa s i predea la termen proiectul aa
cum ar trebui s fie. n loc s delegi task-uri pe 6 sptmni ncearc s
dai activiti pe 2-3 sptmni. i atunci poi s le i spui dac suntei
191
n grafic sau nu.

11. inei prnzuri virtuale, o dat pe lun pentru a construi un raport
non formal al relaiei.
12. Investete n training-uri care s construiasc comportamente de colaborare eficient, comunicare i construirea de comuniti.
13. Fii disponibil - Aa cum am amintit i mai sus, munca virtual poate
s devin izolant. Nu lsa membrii echipei s simt c eti absent,
fii prezent i intr n contact cu ei ct de des, nu doar n legtur cu
task-urile de zi cu zi, ci mai mult, chestiuni legate de starea membrilor
sau viaa lor social.
14. ncurajeaz discuiile informale - Oamenii au tendina de a fi interesai de ceea ce fac alii n viaa personal. Pentru a-i ajuta s i
construiasc relaii puternice, ncurajeaz echipa s i mprteasc
ntmplrile n mod nonformal ct de des.
15. Fii creativ n sudarea echipei - De exemplu, dup ce echipa ta atinge
un obiectiv, organizeaz o ceremonie de premiere virtual. Trimite
mici cadouri membrilor echipei i pune-i pe toi s deschid cadoul
n acelai timp n timpul unei video conferine.
CONCLUZII
Echipele virtuale sunt un fenomen n aflat n cretere i majoritatea executivilor au o atitudine pozitiv asupra beneficiilor acestei formule.
Persoanele care deja lucreaz n echipe virtuale sunt de acord c munca
virtual le permite s colaboreze cu colegi din mai multe organizaii i le
ofer acces la piaa global a talentelor, lucru benefic n competitivitatea organizaiei i al creterii potenialului profesional.
Un lucru cert este c modul n care trebuie gestionate nu este de ignorat,
ba din contra este o provocare bine venit care ne dezvolt autenticitatea n
leadership.
Autor
Monica Soare - Managing Partner @ Artwin
Andreea Prvu
Absolvent a masteratului de Psihologia Resurselor Umane, i-a nceput
cariera ca HR Generalist la o companie de logistic, unde i-a descoperit i
dezvoltat o pasiune pentru aria de Resurse Umane. Experiena international ca membru al echipei globale de Talent Management din cadrul unei
companii de telecomunicaii, a contribuit la dobndirea i mbuntirea
cunotinelor n acest domeniu. n plus, acest context a avut un impact pozitiv n momentul n care a decis s ncerce domeniul IT ca freelancer. Din
2012, Andreea este Senior Recruiter la Endava - Cluj, una dintre companiile
de IT recunoscut ca avnd una din cele mai accelerate creteri pe piaa din
Romnia.
Pe lng activitile corporate, a iniiat cteva proiecte de succes n domeniul educaiei, printre cele mai cunoscute sunt colaborrile cu organizaiile
studeneti clujene pentru oferirea de suport studenilor n definirea unui
career path.
Totodat pentru comunitatea mobile din Cluj, a fost deschizator de
drumuri n dezvoltarea unui proiect Mobile Operation Systems, de mbuntire a abilitilor i cunotinelor tehnice. Proiectul a fost la o prim
ediie, dar vor urma cu siguran i altele. Implicarea n comunitatea de IT
este dovedit i prin publicarea de articole n Today Software Magazine, una
dintre cele mai cunoscute reviste de pe piaa IT clujean.
18
JOCUL RECRUTRII
Modul n care nelegem i ne raportm la contextul actual clujean marcat

de o continu evoluie datorit cunoscutei dinamiciti a pieei de IT se
poate constitui ntr-un interesant subiect de analiz. Documentarea despre
dinamicitate ar fi un prim demers n seria operaiilor de analiz dedicate
acestui subiect. Considerm ns prioritar i concentrarea asupra definiiei
ateniei, care este descris ca funcie sau mecanism de orientare, focalizare
i fixare a contiinei asupra unui obiect, sarcin, ntrebare, problem. Cele
dou concepte, dinamicitatea i atenia, sunt mai mult dect corelate. Pentru a nelege cel mai bine ce se ntmpl n piaa de IT este necesar s fim
ateni i s ne concentrm energia pentru a desfura celelalte procese i
structuri psihice care au un impact n activitatea noastr. Cele trei funcii
eseniale ale ateniei: orientarea, selectarea i concentrarea n vederea proceselor de cunoatere, pe care le subliniaz studiile de specialitate, transformate
n repere importante n analiza specificului contextului IT clujean, ar putea
demonstra necesitatea schimbrii paradigmei n resurse umane. Modalitatea
tradiional de a selecta noi angajai este cauza unor dereglri evidente n
piaa IT clujean, de aceea se impune o redefinire a procesului de selectare
care s valorifice teoriile moderne.
Reprezentanii de resurse umane se situeaz la intersecia dintre nevoia
de business i nevoia angajailor, avnd ca rol s reprezinte ambele interese la
aa numita mas a managerilor printr-o implicare activ n deciziile strategice ale companiei.
194
Schimbarea paradigmei vine din faptul c HR-ul nu mai este vzut ca

funcie suport pentru organizaie, ci este considerat un partener strategic. Iar
pentru aceasta, primul pas care trebuie ntreprins este s devin un consilier
de ncredere pentru a ajunge un expert n domeniul recrutrii.
nc de la nceput va fi clarificat conceptul de candidai activi i pasivi i
care este impactul lor n tot procesul de recrutare. Dac pn n anul 2010
candidaii activi erau prepondereni pe pia i aplicau la joburi, acum n
industria IT situaia s-a schimbat radical i numrul candidailor pasivi este
ntr-o continu cretere. Aadar se impune schimbarea abordrii pentru c
singurul aspect care a rmas nemodificat este angajarea de talente - cheia
unei organizaii de succes. Talentul este combinaia perfect ntre pasiune,
dorina de nvare i performana obinut.
Definiia Talentului
Schimbarea perspectivei va avea un impact major i n ceea ce privete

selecia noilor angajai. n peste 70% din cazuri nc se mai ntmpl ca persoana care are cele mai bune abiliti de comunicare i de prezentare la un
interviu s ocupe postul. Mare parte din cei care particip la interviuri sunt
candidai activi care cred c nu necesit o descriere detaliat, ci doar o
meniune succint, c sunt acea tipologie de angajai care caut activ pe pia.
Atenia va fi concentrat asupra candidailor pasivi. Principala caracteristic
a acestei categorii este dorina de dezvoltare a carierei prin proiecte provocatoare care s aib un business i o arhitectur complex, tehnologii noi i
metodologii de livrare implementate corespunztor pe baza principiilor pe
care le promoveaz. Campaniile de promovare a joburilor vacante targeteaz
un pool de candidai activi i nu pasivi, pentru c ofer oportuniti pe termen scurt i de cele mai multe ori poziii similare. Un java senior developer
are aceleai specificaii ale postului n orice companie. ns un java developer
care vede oportuniti de evoluie n carier i pai clari pe care s i urmeze,
va alege ntotdeauna compania care i ofer acest mediu.
Cum facem s atragem candidai pasivi? n cele ce urmeaz vor fi prezentate dou soluii.
JOCUL RECRUTRII
195
PRIMA SOLUIE
Nu mai folosi anunurile tradiionale i plictisitoare!
Candidaii pasivi nu caut joburi bazate pe abiliti, cunotine i experien ci oportuniti i provocri. Ca s poi face acest lucru, fiecare job description (fia postului) s fie transformat ntr-un job cu adevrat real. Job
description-urile sunt o niruire de cteva elemente: abilii, competene,
studii, iar unele cuprind i o succint prezentare a responsilitilor postului. Practic ele se rezum mai mult la o descriere a persoanei, nu a postului. Schimbarea de paradigm nseamn definirea clar a posibilitilor de
cretere i dezvoltare, responsabilitile i indicatorii de performan pentru
atingerea rezultatelor. Recomandarea este de a se face trecerea ctre nite
profile de performan care s fie folosite n procesul de screening, evaluare
i recrutare pentru fiecare candidat n parte.
Joburile vacante sunt greu de gsit? Pentru c se folosesc n continuare
deja mult prea cunoscutele platforme de joburi online. Prin schimbarea paradigmei, compania trebuie s ajung la candidat ntr-un mod ct mai atractiv.
n contextul n care sunt 11.000 depoziii deschise pe pia i aproximativ
9 000 de IT professionals candidaii nu vor pierde timpul cautnd joburile
vacante. Compania trebuie s vin n ntmpinarea lor cu un site atractiv
dedicat paginii de cariere care s prezinte posibiliti de cretere profesional, acces la training-uri, mediu de lucru prin folosirea de testimoniale
ale persoanelor care deja au un rol n cadrul companiei. Mai mult dect att
SEO i social media vor juca un rol esenial n promovarea companiei pe
pia. O pagin de LinkedIn sau Facebook foarte atractiv care promoveaz
cultura i filosofia companiei, valorile i principiile va fi un atuu n poziionarea companiei ca un angajator preferat.
A DOUA SOLUIE
Arunc la gunoi tot ce tii despre angajri!
Lou Adler spune c 50-60% din angajri se fac pe baza percepiei pe care
intervievatorul o are despre candidat. Emoii, stereotipuri, preri personale
influeneaz luarea deciziei. De menionat este faptul c muli dintre candidai ofer piste false, iar principalul motiv pentru care se ntmpl aceasta
este c nu le sunt adresate ntrebrile corespunztoare. Problema este c se
acord o atenie deosebit interaciunii stabilite cu candidatul ca acesta s
se simt ct mai confortabil i s nu perceap interviul ca pe un interogatoriu
i prea puini dintre cei care recruteaz se concentreaz pe a afla informa-
196
Procesul tipic de angajare
ii ct mai detaliate despre motivaie, experien, abiliti necesare, potrivire

cu cultura organizaional. Nu cred c este un secret, dar majoritatea dintre
acetia iau hotrrea de angajare n primele 30 minute ale interviului. Greit!
Important este s lai informaia s se sedimenteze i abia ulterior s chestionezi i s analizezi fiecare rspuns primit, pn cnd decizia este una ferm.
Cum s faci acest lucru?
Formeaz-i o prere doar la finalul interviului. Intr n fiecare interviu
cu un profil de performan (performance based interview) care s conin
elemente legate de responsabilitile postului, de obiectivele i criteriile de
performan. La finalul interviului noteaz ct mai multe informaii pentru
a avea ancorele necesare lurii deciziei.
Dac vrei s angajezi persoane foarte bune, definete obiective foarte ridicate.
Schimbarea de paradigm nseamn renunarea la criteriile definite pe baza
fiei postului i stabilirea unor indicatori de performan care se ateapt de
la jobul n sine. Fiele de post sunt cele mai inflexibile instrumente care exist
n procesul de recrutare. n contextul dinamic al pieei, sarcinile se modific
constant pe parcursul timpului. Multe dintre fiele de post sunt nvechite i
mare parte din ele sunt fcute pe baza COR-ului. ntr-un mediu de lucru
agile, specificaiile se schimb mereu n funcie de nevoia de business a clientului. Astfel, riscurile folosirii unor astfel de fie de post pot conduce ctre
negsirea candidatului potrivit. Dac nu este identificat se va ajunge n faza
n care se vor face compromisuri. Un alt risc la care companiile se expun este
clonarea reprezentat de gsirea unei copii fidele a celor care deja exist n
companie.
Astfel, procesul nou de recrutare redefinit se va rezuma la trei elemente
cheie.
JOCUL RECRUTRII
197
Elementele cheie n noul proces de recrutare
Cultura organizaional a devenit n prezent o tem de interes mai ales

n contextul n care asistm la internaionalizarea fr precedent a organizaiilor. Poate fi considerat o for invizibil. Ca s facem o paralel, cultura pentru organizaii este ceea ce reprezint personalitatea pentru fiecare
individ. Recentele fuziuni/ achiziii (Kno Intel, Evoline Accenture, EBS
NTT Data) ilustreaz presiunile puse pe identificarea de noi resurse, iar
organizaiile trebuie s devin o prezen activ n toate domeniile.
Aadar ce este cultura organizaional?
Sathe definete cultura ca fiind un set de convingeri mprtite de toi
membrii, acestea sunt reprezentate de valorile companiei, viziunea i misiunea, simbolurile i convingerile definite i trite.
ntr-un mediu dinamic n care companiile pun din ce n ce mai mult accentul pe dezvoltarea angajaiilor, n ultimele decenii fiecare organizaie de
pe glob a ncercat s defineasc elementele care contribuie la crearea acelui
mediu organizaional de succes. Scopul lor este de a determina care sunt indicatorii de performan specifici pentru o organizaie cu un standard ridicat.
Cerinele mediului extern foreaz companiile s se adapteze competiiei internaionale i s fie competitive att din perspectiva preului, calitii, flexibilitii ct i a relaiilor cu clienii. Managerii au dezvoltat un interes pentru
crearea unei culturi organizaionale orientate spre performan i excelen.
O cultur puternic presupune alinierea obiectivelor individuale i cele de
echip cu obiectivele de dezvoltare a afacerii. Astfel nvarea va ocupa un
loc cheie, iar resurse i timp vor fi alocate pentru mbuntirea performanei
organizaiei.
Elementele culturii organizaionale se pot transpune n procesul de recrutare prin trei dimensiuni.
198
Dimensiuni
Filosofia procesului de recrutare

Promovarea poziiei n contextul
dezvoltrii organizaionale
Procesul de selecie- interviul fa

n fa
CE?
Definirea ateptrilor i a filosofiei de angajare
CUM?
Toi evaluatorii cunosc

principiile definite pe
care i le nsuesc
Comunicarea ctre
exterior a culturii
organizaionale
Poziionarea companiei
ca fiind prima opiune a
candidailor (employer of
choice)
Comunicarea strategiilor
de cretere ale companiei
sustenabilitatea i posibilitatea construirii unei
cariere
Evidenierea realizrilor
notabile ale companiei
Definirea indicatorilor necesari

obinerii unei performane ridicate
Crearea ateptrilor corecte

ctre candidai n prezentarea pailor ntregului proces
UNDE?
Intervievatorii
sunt educai i
pregtii intern
Participarea la
evenimente specifice
comunitii
Utilizarea unor
elemente vizuale
care definesc cultura
organizaional
Folosirea de
testimoniale de la
angajai
Crearea unui site
atractiv de cariere care ofer o
descriere detaliat a
elementelor culturii
organizaionale
Revizuirea eforturilor depuse n
procesul de selecie
pentru ocuparea
posturilor vacante
COGNIIE SAU NEUROTIINE

Neurotiinele s-au nfiinat abia ncepnd cu anii 70. n contextul actual,
neurosiinele vor juca un rol esenial. De ce oamenii de HR trebuie s aib
cunotine de baz despre cum funcioneaz creierul uman? Cred c este
mai mult o ntrebare retoric. Primul motiv este legat de faptul c procesul
de persuasiune este unul mult mai eficient dac se fundamenteaz pe nelegerea procesului de funcionare a creierului.
Al doilea motiv este c influeneaz modul n care candidaii raporteaz
propriile convingeri i credine la cultura organizaional. Aa cum menionam i mai sus, un impact pozitiv mare l va avea mereu alinierea culturii
organizaionale cu cea a individului. Cu ct un candidat se regsete mai
mult, cu att va fi mai atras de companie i cu att aportul lui va fi unul mai
mare. Pe de alt parte, neurotiinele ajut la nelegerea procesului care st
JOCUL RECRUTRII
199
n spatele fiecruia De ce? (Ex: De ce ncurajm o filosofie de recrutare? De

ce un mediu n care se ncurajeaz un angajament ridicat funcioneaz doar
pentru anumii candidai? De ce suntem influenai n procesul decizional?)
n cele ce urmeaz voi prezenta ct se poate de succint cum funcioneaz
creierul nostru.
Structura creierului are 3 elemente importante:
Neurocortex Creierul raional
Creierul limbic - Creierul emoional
Creierul reptilian - Creierul instinctiv
Ca recruiter consientizm c structura creierului nostru influeneaz deciziile pe care le lum.
Astfel o sugestie este ca n momentul interviurilor
s dezactivm contient creierul limbic i cel reptilian, pentru a pstra
obiectivitatea pe tot parcursul interaciunii cu candidatul. Raional ne vom
concentra pe cum se vor mapa valorile i principiile candidatului n interiorul
culturii organizaionale i care este valoarea adaugat a fiecrui candidat.
Am ntlnit o teorie nou care ine de schimbarea de paradigm n HR
dezvoltat de Jan Hills n Brain Savy HR despre primordialitatea relaiilor
i nelegerea reaciilor oamenilor. El propune un model care se numete The
CORE care reprezint patru mari arii care intervin n interaciunile sociale
ntre oameni.
The CORE Jab Hills, Brain Savy HR
200
Certitudinea n procesul de recrutare poate atrage candidaii cei mai

buni. Informaii despre planurile de viitor ale companiei, dezvoltarea unei
cariere ntr-un mediu sustenabil sunt elemente care pot transforma compania ntr-o opiune viabil. Pentru a asigura transparena este indicat alocarea unei pri din interviu pentru a explica strategii, planuri, viziune, misiune,
valori, etc. .
Ofer candidailor opiuni , creeaz flexibilitate n abordare.
Reputaia companiei pe pia poate fi ctigat prin diverse metode. Rolul recruiter-ilor este de a asigura transparena procesului de recrutare i prezentarea pailor care urmeaz n procesul de recrutare prin oferirea de feedback
constant i prin pstrarea legturii cu candidaii.
Ultimul element se refer la faptul c fiecare candidat i dorete s fie
tratat cu echitate i s aib anse egale cu toi ceilali implicai n proces.
COMPLEXITATE
Dinamicitatea pieei determin complexitatea procesului de recrutare.
Scopul fiecrui proces de sourcing este de a-i identifica ntr-o perioada scurt
de timp cu costuri ct mai sczute pe cei mai buni candidai de pe pia
n special pe candidaii pasivi mentionai n diverse paragrafe la nceputul
articolului. Mare parte din procesul de sourcing se desfoar pe platformele
online de recrutare. n acest fel, creativitatea este ngrdit i anunurile arat
la fel. Cum ai putea s te atepi la rezultate performante cnd abordarea este
una mediocr?
Schimbarea paradigmei const n definirea unei strategii care s cuprind
mai multe surse:
Sistem integrat care s susin procesul de recrutare i care s aib funcionalitatea de a cumula informaii din diverse surse n timp real i care s ofere
posibilitatea definirii de campanii de marketing targetate diferit pe fiecare
canal de sourcing.
Programul intern de bonusare este o strategie puternic pentru a intra n
contact cu persoane performante care nu caut activ un loc de munc. Este
modalitatea cea mai eficient de a promova cultura organizaional n mediul
extern. Candidaii s vin pentru c feedback-ul din interior este unul pozitiv
i vd un impact n dezvoltarea lor personal i profesional dac vor decide
s fac parte din acelai mediu de lucru.
Consolidarea relaiilor cu universitile prin ncurajarea programelor de internship sau a celor de training pentru proaspeii absolveni, prin participarea
JOCUL RECRUTRII
201
activ n oferirea de burse i premii celor mai buni. Companiile din vest
practic demult acest sistem prin care i asigur un pool de candidai juniori
care vor fi crescui n cultura companiei nc de la nceput.
Evenimente de tipul open days n care candidaii s poat interaciona cu
cultura organizaiei, cu reprezentani din diferite departamente, cu mediul
de lucru, proiecte, tehnologii i metodologii care pot constitui un real interes
pentru cei implicai. Mai mult dect att, astfel de evenimente ncurajeaz
activ networking-ul i consolidarea unei relaii pe termen lung cu candidaii
i o mai bun cunoatere de ambele pri a nevoilor.
Odat identificat modalitatea de promovare a poziiei vacante, schimbarea paradigmei const i n oferirea de cariere pe termen lung nu doar de joburi, aa cum menionam i la nceputul articolului. Doresc s fac urmtoarea
meniune, criteriul financiar este i va fi mereu unul important, dar procesul
decizional al candidailor are la baz cinci factori pe care i vd eliminatorii:
Alinierea obiectivelor de dezvoltare personal i profesional cu cele ale
companiei persoanele performante caut provocri i oportuniti care s
i ajute s evolueze.
A oferi candidatului posibilitatea de a avea o interaciune cu eful direct,
deoarece candidaii foarte buni caut s identifice lideri/ mentori care s i
impulsioneze n atingerea obiectivelor.
Amploarea proiectelor i nivelul tehnologiilor implicate, precum i
echipele angrenate ntr-un mecanism agile care s ofere produse calitative
clientului.
Poziionarea companiei pe pia companiile mari i cu un employer
branding eficient vor atrage ntotdeauna candidai.
Pachetul de beneficii - care s ofere diferite faciliti la transport, sli de
sport, asigurri medicale i de sntate, etc. .
Odat cu atragerea candidailor printr-un proces eficient de sourcing, urmtorul pas este modul n care este condus interviul. Comparaia cea mai la
ndemn este principiul foilor de ceap. Fiecare strat trebuie s reprezinte
un aspect care urmeaz s fie evaluat pn cnd se ajunge la aspectele cele
mai eseniale. n cele ce urmeaz va fi prezentat un decalog al Top 10 predictori folosii n interviuri:
1. Competenele tehnice necesare: nu vor fi detaliate pentru c predictorul
este unul mai mult dect evident n contextul n care discutm despre
industria IT.
2. Potenialul de nvare datorit evoluiei tehnologice, tehnologii sau
202
3.
4.
5.
6.
framework-uri actuale, pot deveni nvechite ntr-o perioad scurt de

timp, iar candidatul este necesar s aib potenialul, dar i dorina de
a acumula noi informaii.
Motivaia energia pe care candidatul este dispus s o investeasc n
a dezvolta pasiune, angajament, perseveren pentru atingerea excelenei. S nu facei compromis niciodat la acest factor. ntr-adevr
procesul de recrutare n IT este uneori greoi i mult prea provocator,
dar mai bine este prelungit pn cnd se va gsi persoana motivat
s fac jobul, altfel riscurile asumate sunt mult prea mari. Insistai
pe parcursul interviului pe situaii n care rezultatele obinute au fost
remarcabile.
Inteligena emoional - Goleman prezint inteligena emoional ca
fiind capacitatea unei persoane de a-i nelege propriile emoii i ale
celorlali din grupul din care face parte. Cred c este nevoie de o
schimbare de paradigm i n ceea ce nseamn deja binecunoscutul
stereotip c oamenii din IT nu au people skills. Abilitatea de a fi
un bun lider se aplic n dou contexte diferite: unul are legtur cu
capacitatea de a ghida i susine creterea persoanelor subordonate,
dar n acelai timp este relevant capacitatea de influenare a deciziilor din cadrul proiectelor. Recomandarea este de a se pune accentul
pe exemple n care candidatul a reuit s medieze un conflict i mai
ales care au fost soluiile gsite, dac a reuit s schimbe o decizie important de business pentru c a crezut cu trie n capacitile tehnice.
Capacitatea de a rezolva probleme i de a identifica soluii pe baza experienei cumulate n trecut. Este esenial s poat face corelaii i s
anticipeze nevoile i problemele nainte ca ele s apar, iar acest lucru
se poate evalua foarte uor prin nelegerea procesului de documentare i aflare a informaiilor relevante care pot impacta o decizie.
Rezultate anterioare obinute corelate cu obiectivele de performan
definite pentru fiecare post, aa cum am menionat chiar la nceputul
articolului, pentru c rezultate anterioare vor fi mereu un predictor
bun pentru rezultatele viitoare. O persoan performant n trecut
ar trebui s fie performant i n viitor. Important este compararea rezultatelor n medii asemntoare, prin o bun evaluare a complexitii sarcinilor de lucru, prin nelegerea ateptrilor clienilor,
prin mrimea echipelor din care a fcut parte sau le-a coordonat, prin
complexitatea problemelor aprute.
JOCUL RECRUTRII
203
7. Definirea unui trend de definire a evoluiei profesionale pe parcursul anilor i identificarea rolurilor pe care candidatul dorete s se concentreze n viitor i cum acestea se mapeaz pe planurile de cretere ale
companiei.
8. Abilitile de organizare i planificare unul din principiile fundamentale din Scrum este capacitatea echipelor de auto-organizare, iar acest
aspect este bine de evaluat pe parcursul interviului. Accentul ar trebui
s fie pus pe capacitatea de a livra n intervalul de timp prestabilit,
modalitatea n care se fac estimrile, user story-uri rmase neterminate
pe sprint.
9. Potrivirea cu cultura organizaional i modul n care se regsete n
viziunea, misiunea i valorile companiei.
10. Caracterul nsumeaz trsturi bine mpmntenite care foarte greu
pot fi modificate. Dac caracterul candidatului are un impact negativ
n echipa din care face parte, sugestia ar fi ca decizia de angajare s nu
fie una favorabil. Toi cei nou predictori analizai anterior pot fi educai, pe cnd modificrile comportamentale care in de caracter sunt
mult mai greu de schimbat, iar volumul de timp alocat este aproape
dublu.
Concluzia articolului este una foarte simpl: nu e nimic mai important
pentru succesul tu i al companiei dect angajarea de talente acei great
people. Un candidat slab nu va ajunge niciodat un angajat de succes orict
de mult ai crede n acest lucru ca recruiter. Este important s angajezi inteligent.
Schimbarea de paradigm a procesului de recrutare va fi elementul de
succes pentru o angajare inteligent.
Succes!
Autor
Andreea Prvu - HR professional @ Endava
Mulumim partenerilor notri
AROBS Transilvania Software SA este companie specializat n dezvoltarea de soluii

software n domeniul navigaiei GPS, aplicaii pentru telefoane mobile i o vast experien
n outsorcing pentru industria de turism, banking, transport, sntate i auto.
Voicu Oprean a nfiinat AROBS n iunie 1998 cu scopul de a le demonstara tinerilor
programatori c i pot construi o carier de succes n dezvoltarea de software i n Romnia,
fr a mai fi nevoii s emigreze. Cei 16 ani de succes i dezvoltare pe care compania i-a
cunoscut se datoreaz acestor specialiti IT care lucreaz pentru proiecte de mare anvergur,
att pentru clieni din strintate ct i pentru clieni din Romnia. n 2014, AROBS nseamn o companie cu 7 sedii n ar i strintate (Cluj, Tg. Mure, Bucureti, Iai, Budapesta, Chiinu, Londra) n care i desfoar activitatea peste 350 de specialiti. Acetia susin
i dezvolt permanent activitatea celor 3 linii principale de business:
Dezvoltarea de soluii software personalizate n regim outsourcing pentru companii din
diverse industrii (turism, auto, sntate, banking), inclusiv aplicaii pentru platformele mobile
Android i iOS. AROBS este unul dintre furnizorii consacrai de soluii software pentru
strintate care n 16 ani de activitate a reuit s stabileasc parteneriate de lung durat cu
companii din Finlanda, Marea Britanie, Suedia, Belgia, Canada, Olanda, Germania i SUA.
Soluii software dedicate pieei interne utilizate de peste 2000 de clieni business din
Romnia: aplicaii de monitorizare prin GPS i management a parcului auto, aplicaii SFA
i CRM de automatizare a vnzrilor i de gestionare a depozitelor i magaziilor, soluia de
automatizare a vnzrii de bilete i legitimaii pentru companiile de transport public, primul
sistem de tip TMC din Romnia de furnizare a informaiilor din trafic n timp real.
Distribuie de sisteme de navigaie GPS n Romnia i Europa de Est. Smailo, brandul
propriu AROBS a devenit n ianuarie 2012 cel mai bine vndut sistem de navigaie din
Romnia iar mpreun cu restul brandurilor din portofoliu (Mio i Becker) au poziionat
compania ca i cel mai mare distribuitor de navigatoare GPS din ar.
Succesul de pia din anii anteriori nregistrat cu GPS-urile Smailo a determinat compania s fac urmtorul pas, i anume s creasc paleta de produse prin includerea sub acelai
brand a tabletelor Android. Cu dimensiuni ale ecranelor de 7, 8 i 9,7, tabletele Smailo
Web Energy sunt destinate utilizatorilor care doresc s aib acces la Internet i aplicaii utile
i de divertisment, dar sunt limitai de buget.
Prin tot ceea ce fac ncerc s promovez un model de munc i via bazat pe respect
reciproc ntre oameni, clieni i comunitate, respect pentru via i mediu. Este un deziderat
personal s creez un echilibru armonios ntre dedicarea profesional i cea familial, care s
se completeze cu activitile sportive i implicarea n comunitate.Voicu Oprean, director
general AROBS Transilvania Software SA.
Gsim cele mai bune echipe.

Le ajutm s i rafineze ideea de start-up. Le ghidm pe calea ctre succes.
Le punem la dispoziie infrastructura necesar pentru a crete i nflori.
Le conectm cu Angel Investors i surse instituionale de Venture Capital
din Silicon Valley. Le conducem ctre mreie.
i apoi, repetm!
Asta facem noi. Ramnei aproape pentru mai multe detalii n curand.
Gemini Solutions Foundry, locul n care ideile prind contur.
www.gemsfoundry.com
Mozaic Works - partenerul tu pentru cretere accelerat

Mozaic Works, nfiinat n 2008, este compania numrul 1 de training i consultan
pentru industriile de IT Software i Computere Science n ariile Agile, Lean i Software
Craftsmanship, n Romnia i Europa Central. Alturi de companiile din Europa interesate
de a dezvolta software de calitate ntr-un timp mai rapid, echipa Mozaic Works contribuie
la creterea rezultatelor prin programe dedicate de training, hands-on coaching/training pe
proiecte, mentoring i consultan.
Cu peste 500 de clieni n Romnia, Belgia, Bulgaria, Finlanda, Frana, Germania, Suedia, UK, Mozaic Works este un catalizator pentru schimbare, productivitate ridicat i nvare accelerat.
Training i workshops (selecie): CSM (Certified Scrum Master), CSPO (Certified
Scrum Product Owner), Advanced Scrum, Lean Kanban, Certified Kanban, Agile Architecture, Agile Design, Agile Management, Agile Leadership, User Stories for Agile Requirements, Test Driven Development, Unit Testing, SOLID principles, Design Patterns,
Refactoring, Product Inception.
Servicii de consultan i coaching (selecie): Agile Transformation/ Agile Adoption,
Lean Kanban Transformation/ Kanban Adoption, Business agility, Seeds for innovation:
Lean Startup, Product development using Agile & Lean principles, Continuous Delivery
(technical practices), Agile Architecture i Incremental Design Adoption.
Clienii notri sunt corporaii naionale i internaionale, companii mici i medii, dar i
startup-uri. Cu implicare n comunitile locale din mai multe orae din Europa, cteva fiind
Bucureti, Cluj Napoca, Hamburg, Oslo, Londra, Viena, echipa Mozaic Works mprtete
cu bucurie din experiena acumulat de-a lungul timpului.
Mozaic Works website: http://www.mozaicworks.com
Mozaic Works blog: http://www.mozaicworks.com/category/blog/
Parteneri
ISBN 978-973-0-17970-5

Cum Se Construieste Un Produs PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Cum Se Construieste Un Produs PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Cum s construieti un

Today Software Magazine

Cum s construieti un produs IT

Cum s construieti un produs IT

Redactor: Ovidiu Man

CUM SE CONSTRUIETE UN PRODUS IT

IT-ul romnesc a cunoscut o evoluie constant n ultimii cincisprezece

CUM SE CONSTRUIETE UN PRODUS IT

ca un impuls pentru noi i inedite subiecte n alte viitoare ediii. De altfel,

Voicu Oprean este un antreprenor concentrat pe dezvoltarea i distribuirea

IT-UL: SIMPLE CIFRE SAU PUTEREA DE A

CUM SE CONSTRUIETE UN PRODUS IT

EVOLUIA. DE LA OUTSOURCING LA PRODUS

CUM SE CONSTRUIETE UN PRODUS IT

Noi, la AROBS ne ghidm dup o filosofie pe ct de simpl pe att de

CLUJUL - SILICON VALLEY

erban r are o experien de 14 ani n lucrul cu companii avnd baza n

CUM SE CONSTRUIETE UN PRODUS IT

SUBIECTE LEGATE DE BUSINESS MODEL

TIPARE DE GNDIRE N ANTREPRENORIAT

oferi, ce nevoie adresezi i de ce ar cumpra cineva de la tine?

CUM SE CONSTRUIETE UN PRODUS IT

TIPARE DE GNDIRE N ANTREPRENORIAT

foarte important ca startup-ul s asculte feedback-ul clienilor pentru a gsi o

CUM SE CONSTRUIETE UN PRODUS IT

mare cu att evaluarea crete. De asemenea crete i ncrederea investitorului

TIPARE DE GNDIRE N ANTREPRENORIAT

TOAT LUMEA ARE CUNOTINE

CUM SE CONSTRUIETE UN PRODUS IT

CUM SE CONSTRUIETE UN PRODUS IT

Sursa imaginii: http://pixabay.com/p-217140/

CUM SE CONSTRUIETE UN PRODUS IT

28-29 May 2015, Bucharest

CUM SE CONSTRUIETE UN PRODUS IT

CUM SE CONSTRUIETE UN PRODUS IT

3. Adugarea la boara user story-urilor i task-urilor ce trebuie fcute i

ACCEPTANCE TEST DRIVEN DEVELOPMENT

CUM SE CONSTRUIETE UN PRODUS IT

I want to find the drug by name

Scenario: Find Aspirin by name

Acum mai bine de un an, la nceputul verii 2013, n timp ce lucram la

CUM SE CONSTRUIETE UN PRODUS IT

cole n cercurile lor de prieteni.

VALIDAREA PROBLEMEI I A SOLUIEI PRIN INTERVIURI

va fi concurena ta direct sau indirect, prin prisma celui intervievat.

CUM SE CONSTRUIETE UN PRODUS IT

Stabilete categorii ale posibililor clieni i clasific interviurile pe diverse pe segmente

VALIDAREA PROBLEMEI I A SOLUIEI PRIN INTERVIURI

diferit, dar complementnd perspectiva validrii problemei i a soluiei. Toi

CUM SE CONSTRUIETE UN PRODUS IT

CELE TREI ETAPE ALE FILOSOFIEI I

CUM PUTEM GNDI INTERACTIV USER EXPERIENCE-UL?

CUM SE CONSTRUIETE UN PRODUS IT

REZOLVRILE CELOR TREI ETAPE

CUM PUTEM GNDI INTERACTIV USER EXPERIENCE-UL?

CUM SE CONSTRUIETE UN PRODUS IT

colateral, iar ceea ce conteaz cu adevrat e doar impresia artistic care s

CUM PUTEM GNDI INTERACTIV USER EXPERIENCE-UL?

Construirea unui produs software viabil este un proces complex, de durat,

#1 CONSTRUIM PENTRU OAMENI

CUM SE CONSTRUIETE UN PRODUS IT

puterelor i dispozitivelor ce ncorporeaz tehnologie nalt. Avem de-a face

#2 OAMENII VOR S SE SIMT BINE