đ„Si tĂ« arrish nĂ« qiell dhe tĂ« bĂ«hesh pilot | ProHoster
Më quajnë Mikhail, jam zëvendësdrejtor për IT në kompaninë «Sportmaster». Dua të ndaj një histori se si u përballëm me sfidat që u shfaqën gjatë pandemisë.
Në ditët e para të realiteteve të reja, formati tradicional i tregtisë offline të «Sportmaster» u ndal, dhe ngarkesa në kanalin tonë online, kryesisht në lidhje me dorëzimin tek klientët, u rrit dhjetëfish. Brenda disa javësh, ne transformuam një biznes të madh offline në online, duke e adaptuar shërbimin sipas nevojave të klientëve tanë.
NĂ« thelb, ajo qĂ« ishte njĂ« operacion dytĂ«sor pĂ«r ne, u bĂ« biznesi kryesor. RĂ«ndĂ«sia e çdo porosie online u rrit ekstremisht. Duhej tĂ« ruanim çdo lek qĂ« klientĂ«t sjellin nĂ« kompani.Â
Për t'u përgjigjur shpejt kërkesave të klientëve, hapëm një qendër kontakti shtesë në zyrën qendrore të kompanisë, dhe tani mund të pranojmë rreth 285,000 telefonata në javë. Në të njëjtën kohë, ne kaluam 270 dyqane në një format të ri pa kontakt dhe të sigurt, çka lejoj klientët të merrnin porositë, ndërsa punonjësit ruanin vendet e tyre të punës.
GjatĂ« procesit tĂ« transformimit, kishim dy probleme kryesore. SĂ« pari, ngarkesa nĂ« burimet tona online u rrit ndjeshĂ«m (se si u pĂ«rballĂ«m me kĂ«tĂ«, do ta tregojĂ« Sergey). SĂ« dyti, fluksi i operacioneve tĂ« rralla (para COVID) u rrit shumĂ«fish, çka kĂ«rkonte njĂ« volum tĂ« madh automatizimi tĂ« shpejtĂ«. PĂ«r tĂ« zgjidhur kĂ«tĂ« problem, na duhej tĂ« rishpĂ«rndanim burimet nga drejtimet qĂ« ishin mĂ« parĂ« kryesore. Si u pĂ«rballĂ«m me kĂ«tĂ« â do ta tregojĂ« Elena.
Shfrytëzimi i shërbimeve online
Kolesnikov Sergey, përgjigjet për shfrytëzimin e dyqanit online dhe mikroshërbimeve
QĂ« nga momenti kur dyqanet tona me pakicĂ« filluan tĂ« mbyllen pĂ«r vizitorĂ«t, ne filluam tĂ« regjistronim rritje tĂ« treguesve si numri i pĂ«rdoruesve, numri i porosive qĂ« bĂ«hen nĂ« aplikacionin tonĂ«, numri i kĂ«rkesave pĂ«r aplikacionet.Â
Numri i porosive nga 18 deri mĂ« 31 mars
Numri i kĂ«rkesave pĂ«r mikroshĂ«rbimet e pagesave online
Numri i porosive të realizuara në faqen e internetit
NĂ« grafikun e parĂ« shohim se rritja ishte pĂ«rafĂ«rsisht 14 herĂ«, ndĂ«rsa nĂ« tĂ« dytin â 4 herĂ«. TĂ« dhĂ«nat mĂ« treguese pĂ«r ne konsiderojmĂ« koha e pĂ«rgjigjes sĂ« aplikacioneve tona.Â
Në këtë grafik shohim përgjigjen e fronteve dhe aplikacioneve, dhe për ne e kemi përcaktuar se nuk kemi vërejtur ndonjë rritje të tillë.
Së pari, kjo lidhet me faktin se ne filluam punët përgatitore në fund të vitit 2019. Tani shërbimet tona janë të rezervuara, është siguruar qëndrueshmëria në nivelin e serverëve fizikë, sistemeve të virtualizimit, konteinerëve dhe shërbimeve në to. Megjithatë, kapacitetet e burimeve tona serverike na lejojnë të përballojmë ngarkesa të shumëfishta.
Instrumenti kryesor qĂ« na ndihmoi nĂ« tĂ« gjithĂ« kĂ«tĂ« histori ishte sistemi ynĂ« i monitorimit. MegjithatĂ«, edhe para pak kohĂ«sh ne nuk kishim njĂ« sistem tĂ« vetĂ«m qĂ« tĂ« na ndihmonte tĂ« mbledhim metrika nĂ« tĂ« gjitha nivelet, nga niveli i pajisjeve fizike dhe harduerit deri te metrikat e biznesit.Â
Formalisht, monitorimi ekzistonte në kompani, por zakonisht ishte i shpërndarë dhe në përgjegjësinë e njësive të veçanta. Faktikisht, kur ndodhte ndonjë incident, ne pothuajse kurrë nuk kishim një kuptim të përbashkët se çfarë kishte ndodhur, nuk kishte njoftim, dhe shpesh kjo çonte në një kërkim pa fund për lokalizimin dhe zgjidhjen e problemit.
NĂ« njĂ« moment, ne menduam dhe vendosĂ«m se ishte e mjaftueshme â na nevojitej njĂ« sistem i vetĂ«m qĂ« tĂ« shihnim tĂ« gjithĂ« pamjen plotĂ«sisht. TeknologjitĂ« kryesore nĂ« stogun tonĂ« pĂ«rfshijnĂ« Zabbix si qendĂ«r pĂ«r paralajmĂ«rim dhe ruajtjen e metrikave, Prometheus pĂ«r mbledhjen dhe ruajtjen e metrikave tĂ« aplikacioneve, Stack ELK pĂ«r regjistrimin dhe ruajtjen e tĂ« dhĂ«nave tĂ« gjithĂ« sistemit tĂ« monitorimit, si dhe Grafana pĂ«r vizualizimin, Swagger, Docker dhe gjĂ«ra tĂ« tjera tĂ« dobishme dhe tĂ« njohura pĂ«r ju.
Gjithashtu, ne pĂ«rdorim jo vetĂ«m teknologjitĂ« qĂ« janĂ« tĂ« disponueshme nĂ« treg, por zhvillojmĂ« edhe disa gjĂ«ra vetĂ«. PĂ«r shembull, ne krijojmĂ« shĂ«rbime pĂ«r integrimin e sistemeve me njĂ«ra-tjetrĂ«n, domethĂ«nĂ« njĂ« API pĂ«r mbledhjen e metrikave. Gjithashtu punojmĂ« mbi sistemet tona tĂ« monitorimit â nĂ« nivelin e metrikave tĂ« biznesit pĂ«rdorim teste UI. Po ashtu, kemi njĂ« bot nĂ« Telegram pĂ«r njoftimin e ekipeve.
Dhe ne gjithashtu pĂ«rpiqemi ta bĂ«jmĂ« sistemin e monitorimit tĂ« aksesueshĂ«m pĂ«r ekipet, nĂ« mĂ«nyrĂ« qĂ« ato tĂ« mund tĂ« ruajnĂ« metrikat e tyre dhe tĂ« punojnĂ« me to, pĂ«rfshirĂ« konfigurimin e paralajmĂ«rimeve nĂ« disa metrika tĂ« ngushta qĂ« nuk kanĂ« njĂ« pĂ«rdorim shumĂ« tĂ« gjerĂ«.Â
NĂ« kuadĂ«r tĂ« gjithĂ« sistemit, ne synojmĂ« proaktivitetin dhe lokalizimin e shpejtĂ« tĂ« incidenteve. PĂ«r mĂ« tepĂ«r, numri i mikrosistemeve dhe sistemeve tona ka pĂ«suar njĂ« rritje tĂ« ndjeshme kohĂ«t e fundit, duke shkaktuar edhe rritjen e numrit tĂ« integrimeve. Si pjesĂ« e optimizimit tĂ« procesit tĂ« diagnostikimit tĂ« incidenteve nĂ« nivelin e integrimit, ne jemi duke zhvilluar njĂ« sistem qĂ« lejon kontrollin ndĂ«r-sistemor dhe nxjerrjen e rezultateve, duke ndihmuar nĂ« identifikimin e problemeve kryesore lidhur me importet dhe ndĂ«rveprimin midis sistemeve.Â
Natyrisht, kemi ende shumĂ« pĂ«r tĂ« rritur dhe zhvilluar nĂ« fushĂ«n e operimit tĂ« sistemeve, dhe jemi duke punuar intensivisht mbi kĂ«tĂ«. MĂ« shumĂ« rreth sistemit tonĂ« tĂ« monitorimit mund tĂ« lexoni .Â
Testet teknikeÂ
Sergei Orlov, drejton qendrën e kompetencës për zhvillimin e uebit dhe mobilit
QĂ« nga fillimi i mbylljes sĂ« dyqaneve fizike, na Ă«shtĂ« dashur tĂ« pĂ«rballim prova tĂ« ndryshme nga pikĂ«pamja e zhvillimit. NĂ« radhĂ« tĂ« parĂ«, njĂ« rritje e ngarkesĂ«s si e tillĂ«. ĂshtĂ« e qartĂ« se nĂ«se nuk merren masa pĂ«rkatĂ«se, me njĂ« ngarkesĂ« tĂ« madhe, sistemi mund tĂ« shndĂ«rrohet nĂ« njĂ« pĂ«rvojĂ« tĂ« pakĂ«ndshme, ose tĂ« degradon nĂ« performancĂ«, ose madje tĂ« humbas kompleksi i funksionimit tĂ« tij.
Aspakti i dytë, pak më pak i dukshëm, është se sistemi nën ngarkesë të lartë duhej të ndryshohej shumë shpejt, duke u adaptuar për ndërrimet e proceseve të biznesit. Herë pas here disa herë në ditë. Në shumë kompani ka një rregull që gjatë aktiviteteve të mëdha marketingu nuk duhet të bëhen asnjë ndryshim në sistem. Asnjë, le të funksionojë siç është.
Por ne kishim, në thelb, një të premte të pakufizuar të zezë, gjatë së cilës duhej të ndryshonim sistemin. Dhe çdo gabim, problem, ose dështim në sistem do të ishte shumë i kushtueshëm për biznesin.
Duke kaluar përpara, mund të them se arritëm të përballojmë këto prova, të gjitha sistemet përballuan ngarkesën, u shkallëzuan lehtësisht, dhe nuk patëm ndonjë dështim teknik të rëndësishëm.
Ekzistojnë katër shtylla mbi të cilat mbështetet aftësia e sistemit për të përballuar ngarkesa të larta rampë. Shtylla e parë është monitorimi, për të cilin keni lexuar më lart. Pa një sistem të ndërtuar monitorimi, është praktikisht e pamundur të gjejmë ngushticat e sistemit. Një sistem i mirë monitorimi është si veshja e shtëpisë, ai duhet të jetë i rehatshëm dhe i adaptuar për ju.
Aspekti i dytë është testimi. Ne e marrim këtë moment shumë seriozisht: shkruajmë teste klasike unitare, integruese, teste ngarkese dhe shumë të tjera për çdo sistem. Gjithashtu, ne shkruajmë një strategji testimi dhe përpiqemi ta çojmë nivelin e testimit deri sa kontrolli manual të mos na nevojitet më.
Shtylla e tretë është CI/CD Pipeline. Proceset e ndërtimit, testimit dhe shpërndarjes së aplikacionit duhet të jenë sa më të automatizuara, nuk duhet të ketë ndërhyrje manuale. Tematika CI/CD Pipeline është mjaft e thellë dhe unë do ta prek vetëm pak. Duhet përmendur vetëm se ne kemi një listë kontrolli CI/CD Pipeline, me të cilën çdo ekip produkti kalon përmes qendrave të kompetencës.
Ja lista e kontrollit
Kështu arrihen shumë qëllime. Kjo përfshin versionimin e API-së, dhe feature toggle, për të shmangur trenin e lëshimeve, si dhe arritjen e mbulimit të testeve të ndryshme në një nivel të tillë sa të automatizohet plotësisht testimi, dhe shpërndarjet të jenë pa ndërprerje etj.
Shtylla e katërt janë parimet arkitektonike dhe zgjidhjet teknike. Mund të flasim shumë dhe gjatë për arkitekturën, por dëshiroj të theksoj disa parime mbi të cilat dëshiroj të përqendrohem.
SĂ« pari, duhet tĂ« zgjidhni mjete tĂ« specializuara pĂ«r detyra tĂ« caktuara. Po, duket e qartĂ«, dhe Ă«shtĂ« e qartĂ« se pĂ«r tĂ« goditur gozhdĂ« duhen pĂ«rdorur çekiç, ndĂ«rsa pĂ«r tĂ« çmontuar orĂ«t duhen pĂ«rdorur dhĂ«mbĂ«z tĂ« veçantĂ«. Por nĂ« epokĂ«n tonĂ«, shumĂ« mjete synojnĂ« tĂ« jenĂ« universale, pĂ«r tĂ« pĂ«rfshirĂ« njĂ« segment maksimal pĂ«rdoruesish: bazat e tĂ« dhĂ«nave, cachĂ«t, framework-et dhe tĂ« tjera. PĂ«r shembull, nĂ«se marrim bazĂ«n e tĂ« dhĂ«nave MongoDB, ajo punon me transaksione multidokumentar, ndĂ«rsa baza e tĂ« dhĂ«nave Oracle punon me json. Dhe duket se gjithçka mund tĂ« pĂ«rdoret pĂ«r çdo gjĂ«. Por nĂ«se ne jemi pĂ«r performancĂ«n, duhet tĂ« kuptojmĂ« qartĂ« pikĂ«t e forta dhe tĂ« dobĂ«ta tĂ« çdo mjeti dhe tĂ« pĂ«rdorim ato qĂ« na nevojiten pĂ«r klasĂ«n tonĂ« tĂ« detyrave.Â
Së dyti, gjatë projektimit të sistemeve, çdo rritje e kompleksitetit duhet të jetë e arsyetuar. Duhet të mbajmë vazhdimisht këtë në mendje; parimi i low coupling është i njohur për të gjithë. Unë besoj se ai duhet të zbatohet si në nivelin e shërbimit konkret, ashtu edhe në atë të gjithë sistemit, dhe në nivelin e peizazhit arkitektural. Gjithashtu, është e rëndësishme të kemi aftësinë e shkallëzimit horizontal të çdo komponente të sistemit në rast ngarkese. Nëse kemi këtë aftësi, shkallëzimi nuk do të jetë asnjëherë një problem.
Nëse flasim për zgjidhje teknike, kemi kërkuar nga ekipet produktore të përgatisin një set të ri rekomandimesh, idesh dhe zgjidhjesh që ata kanë realizuar gjatë përgatitjes për valën e ardhshme të ngarkesës.
Cachët
ĂshtĂ« e nevojshme tĂ« qasemi me vetĂ«dije ndaj zgjedhjes sĂ« cachĂ«ve lokale dhe tĂ« shpĂ«rndarĂ«. NdonjĂ«herĂ« ka kuptim tĂ« pĂ«rdoren tĂ« dyja brenda njĂ« sistemi. PĂ«r shembull, ne kemi sisteme, ku njĂ« pjesĂ« e tĂ« dhĂ«nave nĂ« thelb Ă«shtĂ« njĂ« cache vitrine, domethĂ«nĂ« burimi i pĂ«rditĂ«simeve ndodhet jashtĂ« vetĂ« sistemit, dhe sistemi nuk e ndĂ«rron atĂ« tĂ« dhĂ«nĂ«. PĂ«r kĂ«tĂ« qasje ne pĂ«rdorim Caffeine Cache lokale.Â
Dhe ka të dhëna që sistemi i ndryshon aktivisht gjatë punës, dhe këtu aplikojmë cache-n e shpërndarë me Hazelcast. Kjo qasje na mundëson të shfrytëzojmë avantazhet e cache-së së shpërndarë atje ku ato vërtet janë të nevojshme dhe të minimizojmë shpenzimet shërbyese për qarkullimin e të dhënave në klasterin Hazelcast atje ku mund të ja dalim pa to. Kemi shkruar shumë për cache-t. dhe .
PĂ«r mĂ« tepĂ«r, kalimi nĂ« serializuesin Kryo nĂ« Hazelcast na ka dhĂ«nĂ« njĂ« rritje tĂ« mirĂ«. Dhe kalimi nga ReplicatedMap nĂ« IMap + Near Cache nĂ« Hazelcast na ka lejuar tĂ« minimizojmĂ« lĂ«vizjen e tĂ« dhĂ«nave nĂ«pĂ«r klaster.Â
Një këshillë e vogël: kur bëni invalidimin masiv të caches, nganjëherë aplikohet taktika e ngrohjes së caches të dytë me kalimin e mëpasshëm në të. Mund të duket se, me këtë qasje, duhet të kemi një konsum të dyfishtë të memories, por në praktikë, në ato sisteme ku kjo është praktikuar, konsumimi i memories është zvogëluar.
Staku reaktiv
Ne përdorim stakun reaktiv në një numër të konsiderueshëm sistemesh. Në rastin tonë, kjo është Webflux ose Kotlin me korutina. Staku reaktiv është veçanërisht efektiv aty ku presim operacione të ngadalta të input-output. Për shembull, thirrje të shërbimeve të ngadalta, punë me sistemin e skedarëve ose me sistemet e ruajtjes.
Principi mĂ« i rĂ«ndĂ«sishĂ«m Ă«shtĂ« tĂ« shmangni thirrjet bllokuese. NĂ«n kapakun e framework-eve reaktive, ka njĂ« numĂ«r tĂ« vogĂ«l shĂ«rbimesh aktive. NĂ«se me kujdes lejojmĂ« veten tĂ« bĂ«jmĂ« njĂ« thirrje tĂ« drejtpĂ«rdrejtĂ« bllokuese, si thirrjen e driver-it JDBC, sistemi thjesht do tĂ« ndalojĂ«.Â
Dëshironi të ktheni gabimet në përjashtime runtime të vetat. Procesi real i ekzekutimit të programit kalon në framework-et reaktive, ekzekutimi i kodit bëhet jo-lineare. Si pasojë, është shumë e vështirë të diagnostikosh problemet përmes stack-trace-ve. Zgjidhja këtu do të ishte krijimi i përjashtimeve runtime objektive dhe të qarta për çdo gabim.
Elasticsearch
Kur pĂ«rdorni Elasticsearch, mos zgjidhni tĂ« dhĂ«na qĂ« nuk pĂ«rdoren. Ky Ă«shtĂ« njĂ« kĂ«shillĂ« shumĂ« e thjeshtĂ«, por shpesh harrohet. NĂ«se duhet tĂ« zgjidhni mĂ« shumĂ« se 10,000 regjistrime njĂ«herĂ«sh, duhet tĂ« pĂ«rdorni Scroll. NĂ«se bĂ«jmĂ« njĂ« analogji, Ă«shtĂ« paksa si njĂ« kursori nĂ« njĂ« bazĂ« tĂ« dhĂ«nash relationale.Â
Mos pĂ«rdorni postfilter pa nevojĂ«. Me tĂ« dhĂ«na tĂ« mĂ«dha nĂ« pĂ«rzgjedhjen kryesore, kjo operacion ngarkon shumĂ« bazĂ«n e tĂ« dhĂ«nave.Â
Përdorni operacione bulk aty ku është e aplikueshme.
API
Kur projektoni API, vendosni kërkesa për minimizimin e të dhënave të transferuara. Kjo është veçanërisht e rëndësishme në ndërlidhjen me frontin: pikërisht në këtë pikë ne dalim përtej kanaleve të Qendrave tona të të Dhënave dhe tashmë punojmë në kanalin që na lidh me klientin. Nëse ka probleme të vogla atje, trafik i tepërt e sjell një përvojë negative për përdoruesin.
Dhe, më në fund, mos e derdhni të gjithë masën e të dhënave, qartë qasuni kontratës mes konsumatorëve dhe furnizuesve.
Transformimi organizativ
Eroshkina Elena, zëvendës drejtoreshë për IT
NĂ« momentin kur ndodhi karantina dhe u shfaq nevoja pĂ«r tĂ« rritur ndjeshĂ«m ritmin e zhvillimit online dhe pĂ«r tĂ« zbatuar shĂ«rbime omnichannel, ne ishim tashmĂ« nĂ« procesin e transformimit organizativ.Â
Një pjesë e strukturës tonë u kalua në punën sipas parimeve dhe praktikave të qasjes produktive. U formuan ekipe, të cilat tani janë përgjegjëse për funksionimin dhe zhvillimin e secilit produkt. Punonjësit në këto ekipe janë angazhuar në 100% dhe e organizojnë punën e tyre sipas Scrum ose Kanban, në varësi të asaj që është më e preferueshme për ta, rregullojnë linjën e shtrirjes, zbatojnë praktikat teknike, praktikat e sigurimit të cilësisë dhe shumë të tjera.
Me fat, pjesa më e madhe e atyre ekipeve produktive ndodhej pikërisht në fushën e shërbimeve online dhe omnichannel. Kjo na lehtësoi të kalonim në mënyrë të shpejtë (seriozisht, për dy ditë) në një mod nga distanca pa humbur efikasitetin. Procesi i vendosur na lejoi të adaptoheshim shpejt në kushtet e reja të punës dhe të mbanim një ritëm të mjaftueshëm të dorëzimit të funksionaliteteve të reja.
PĂ«r mĂ« tepĂ«r, na u shfaq nevoja tĂ« forcojmĂ« ato ekipe qĂ« ndodhen nĂ« frontierin e biznesit online. NĂ« atĂ« moment, u bĂ« e qartĂ« se mund ta bĂ«nim kĂ«tĂ« vetĂ«m pĂ«rmes burimeve tĂ« brendshme. Dhe rreth 50 njerĂ«z brenda dy javĂ«sh ndryshuan fushĂ«n, ku kishin punuar mĂ« parĂ« dhe u integruan nĂ« punĂ«n mbi njĂ« produkt tĂ« ri pĂ«r ta.Â
PĂ«r kĂ«tĂ«, nuk nevojiteshin ndonjĂ« pĂ«rpjekje tĂ« veçanta menaxheriale, sepse pĂ«rveç organizimit tĂ« procesit tonĂ«, me pĂ«rmirĂ«simin teknik tĂ« produktit, me praktikat e sigurimit tĂ« cilĂ«sisĂ«, ne i mĂ«sojmĂ« ekipet tona pĂ«r autodashuri â tĂ« menaxhojnĂ« procesin e tyre tĂ« prodhimit pa angazhuar burime administrative.
Ne menaxhuar burimin, arritĂ«m ta fokusohemi pikĂ«risht aty ku ishte e nevojshme nĂ« atĂ« moment, - nĂ« koordinimin me biznesin: ĂfarĂ« Ă«shtĂ« aktualisht e rĂ«ndĂ«sishme pĂ«r klientin tonĂ«, cila funksionalitet duhet tĂ« implementohet si prioritet, çfarĂ« duhet tĂ« bĂ«jmĂ« pĂ«r tĂ« rritur kapacitetin tonĂ« pĂ«r dĂ«rgesĂ« dhe pĂ«rpunim tĂ« porosive. TĂ« gjitha kĂ«to dhe njĂ« model i qartĂ« role na lejuan qĂ« nĂ« kĂ«tĂ« periudhĂ« tĂ« mundohemi tĂ« ngarkojmĂ« proceset tona prodhuese me atĂ« qĂ« Ă«shtĂ« vĂ«rtet e rĂ«ndĂ«sishme dhe e nevojshme.Â
E qartë, në punën e largët dhe me ritmin e lartë të ndryshimeve, kur pjesëmarrja e secilit ndikon në treguesit e biznesit, nuk mund të mbështetemi vetëm në ndjenjat e brendshme si "A po na shkon mirë? Po, mendoj se po". Kërkohen matjet objektive të procesit prodhues. Këto i kemi, janë të-accessueshme për secilin këtu që interesohet për matjet e ekipeve produktive. Para gjithçkaje, për ekipin e vet, biznesin, kolegët dhe menaxhmentin.
Ădo dy javĂ« me secilĂ«n ekip organizohet njĂ« status, ku pĂ«r 10 minuta analizohen metrikat, identifikohen ngushticat e procesit prodhues dhe zhvillohet njĂ« zgjidhje e pĂ«rbashkĂ«t: çfarĂ« mund tĂ« bĂ«het qĂ« kĂ«to ngushtica tĂ« eliminohen. Po ashtu, mund tĂ« kĂ«rkohet menjĂ«herĂ« ndihma nga menaxhmenti nĂ«se ndonjĂ« problem i identifikuar ndodhet jashtĂ« zonĂ«s sĂ« influencĂ«s sĂ« ekipeve, ose ekspertizĂ«s sĂ« kolegĂ«ve tĂ« cilĂ«t, ndoshta, kanĂ« hasur nĂ« probleme tĂ« ngjashme.
Megjithatë, ne e kuptojmë se për të shpejtuar shumë herë (sikur e kemi vendosur këtë si qëllim), na nevojitet të mësojmë shumë gjëra dhe t'i implementojmë në punën tonë të përditshme. Tani jemi duke vazhduar me shkallëzimin e qasjes produktive në ekipe të tjera dhe në produkte të reja. Për këtë na ndihmoi të përvetësojmë një format të ri për ne, shkollën online për metodologët.
MetodologĂ«t, njerĂ«zit qĂ« ndihmojnĂ« ekipet tĂ« ndĂ«rtkojnĂ« procesin, tĂ« pĂ«rmirĂ«sojnĂ« komunikimin, tĂ« rrisin efikasitetin e punĂ«s, nĂ« thelb janĂ« agjentĂ« tĂ« ndryshimit. Tani, absolvimet tona tĂ« grupit tĂ« parĂ« po punojnĂ« me ekipet dhe u ndihmojnĂ« atyre tĂ« bĂ«hen tĂ« suksesshĂ«m.Â
Mendoj se situata që kemi krijuar ofron mundësi dhe perspektiva të tilla, të cilat ndoshta as ne nuk i kuptojmë plotësisht ende. Por përvoja dhe praktika që po fitojmë tani konfirmojnë se kemi zgjedhur rrugën e duhur të zhvillimit, nuk do të humbasim këto mundësi të reja në të ardhmen dhe do të jemi gjithashtu në gjendje të përgjigjemi në mënyrë efektive ndaj sfidave që do të paraqiten për "Sportmaster".
PĂ«rfundimet
Gjatë këtij kohe të vështirë, ne formuluam parimet kryesore mbi të cilat mbështetet zhvillimi i softuerit, të cilat mendoj se do të vlejnë për çdo kompani që merret me këtë.
NjerĂ«zitKjo Ă«shtĂ« ajo mbi tĂ« cilĂ«n bazohet gjithçka. PunonjĂ«sit duhet tĂ« gĂ«zojnĂ« nga puna, tĂ« kuptojnĂ« qĂ«llimet e kompanisĂ« dhe qĂ«llimet e produkteve me tĂ« cilat merret. Dhe, natyrisht, tĂ« kenĂ« mundĂ«si pĂ«r zhvillim profesional.Â
ShkencaĂshtĂ« e nevojshme qĂ« kompania tĂ« afrojĂ« njĂ« qasje tĂ« zhvilluar ndaj punĂ«s me stivĂ«n e saj teknologjike dhe tĂ« rrisĂ« kompetencat atje ku Ă«shtĂ« realisht e nevojshme. TingĂ«llon shumĂ« e thjeshtĂ« dhe e dukshme. Dhe shpesh neglizhohet.
ProcesetĂshtĂ« e rĂ«ndĂ«sishme tĂ« organizohet siç duhet puna e ekipeve tĂ« produkteve dhe qendrave tĂ« kompetencĂ«s, pĂ«r tĂ« ndĂ«rtuar bashkĂ«punimin me biznesin, nĂ« mĂ«nyrĂ« qĂ« tĂ« punosh me tĂ« si njĂ« partner.
Në përgjithësi, kështu e kaluam. Teza kryesore e kohërave moderne u konfirmua edhe një herë, duke bërë një goditje të fortë në ballë.
Edhe nëse je një biznes i madh offline me shumë dyqane dhe shumë qytete, zhvillo online tëndin. Nuk është thjesht një kanal shtesë shitjeje apo një aplikacion i bukur, përmes të cilit gjithashtu mund të blihen gjëra (edhe sepse konkurentët kanë gjithashtu një aplikacion të bukur). Nuk është një rezervë për çdo rast, që do të ndihmojë për të kaluar stuhinë.
ĂshtĂ« njĂ« nevojĂ« e vĂ«rtetĂ«. PĂ«r tĂ« cilĂ«n duhet tĂ« jenĂ« tĂ« gatshĂ«m jo vetĂ«m kapacitetet teknike dhe infrastruktura, por edhe njerĂ«zit dhe proceset. Sepse, blerja e shpejtĂ« e memories, hapĂ«sirĂ«s, shpĂ«rndarja e instancave tĂ« reja dhe tĂ« tjera mund tĂ« bĂ«het pĂ«r disa orĂ«. Por njerĂ«zit dhe proceset duhet tĂ« pĂ«rgatiten paraprakisht pĂ«r njĂ« gjĂ« tĂ« tillĂ«.
Burimi: habr.com
