Kas palÄ«dzēja mums ātri pielāgoties tieÅ”saistes tirdzniecÄ«bai jaunajos apstākļos

Hi!

Mani sauc Mihails, es esmu IT direktora vietnieks uzņēmumā Sportmaster. Es vēlos dalīties stāstā par to, kā mēs tikām galā ar izaicinājumiem, kas radās pandēmijas laikā.

Jaunās realitātes pirmajās dienās iesaldēja Sportmaster parastais bezsaistes tirdzniecÄ«bas formāts, un mÅ«su tieÅ”saistes kanāla slodze, galvenokārt piegādes ziņā uz klienta adresi, pieauga 10 reizes. Tikai dažu nedēļu laikā mēs pārveidojām milzÄ«gu bezsaistes biznesu par tieÅ”saistes biznesu un pielāgojām pakalpojumu mÅ«su klientu vajadzÄ«bām.

BÅ«tÄ«bā tas, kas bÅ«tÄ«bā bija mÅ«su blakus darbÄ«ba, kļuva par mÅ«su pamatdarbÄ«bu. Katra tieÅ”saistes pasÅ«tÄ«juma nozÄ«me ir ārkārtÄ«gi pieaugusi. Bija nepiecieÅ”ams ietaupÄ«t katru rubli, ko klients atnesa uzņēmumam. 

Kas palÄ«dzēja mums ātri pielāgoties tieÅ”saistes tirdzniecÄ«bai jaunajos apstākļos

Lai ātri reaģētu uz klientu pieprasÄ«jumiem, uzņēmuma galvenajā birojā atvērām papildu kontaktu centru, un tagad varam saņemt aptuveni 285 tÅ«kstoÅ”us zvanu nedēļā. Vienlaikus 270 veikalus pārcēlām uz jaunu bezkontakta un droÅ”u darbÄ«bas formātu, kas ļāva klientiem saņemt pasÅ«tÄ«jumus un darbiniekiem saglabāt darba vietas.

PārveidoÅ”anas procesā mēs saskārāmies ar divām galvenajām problēmām. Pirmkārt, mÅ«su tieÅ”saistes resursu slodze ir ievērojami palielinājusies (Sergejs pastāstÄ«s, kā mēs ar to tikām galā). Otrkārt, reto (pirms COVID) operāciju plÅ«sma ir daudzkārt palielinājusies, kas savukārt prasÄ«ja lielu strauju automatizāciju. Lai atrisinātu Å”o problēmu, mums bija ātri jāpārnes resursi no jomām, kas iepriekÅ” bija galvenās. Elena pastāstÄ«s, kā mēs ar to tikām galā.

TieŔsaistes pakalpojumu darbība

Koļesņikovs Sergejs, atbildīgs par interneta veikala darbību un mikropakalpojumiem

No brīža, kad mÅ«su mazumtirdzniecÄ«bas veikalus sāka slēgt apmeklētājiem, mēs sākām reÄ£istrēt tādu rādÄ«tāju pieaugumu kā lietotāju skaits, mÅ«su lietojumprogrammā veikto pasÅ«tÄ«jumu skaits un lietojumprogrammām iesniegto pieprasÄ«jumu skaits. 

Kas palÄ«dzēja mums ātri pielāgoties tieÅ”saistes tirdzniecÄ«bai jaunajos apstākļosPasÅ«tÄ«jumu skaits no 18. marta lÄ«dz 31. martamKas palÄ«dzēja mums ātri pielāgoties tieÅ”saistes tirdzniecÄ«bai jaunajos apstākļosPieprasÄ«jumu skaits tieÅ”saistes maksājumu mikropakalpojumiemKas palÄ«dzēja mums ātri pielāgoties tieÅ”saistes tirdzniecÄ«bai jaunajos apstākļosVietnē veikto pasÅ«tÄ«jumu skaits

Pirmajā grafikā redzams, ka pieaugums bija aptuveni 14 reizes, otrajā - 4 reizes. Mēs uzskatām, ka mÅ«su lietojumprogrammu reakcijas laika metrika ir orientējoŔākā. 

Kas palÄ«dzēja mums ātri pielāgoties tieÅ”saistes tirdzniecÄ«bai jaunajos apstākļos

Å ajā grafikā mēs redzam frontes un lietojumprogrammu reakciju, un mēs paÅ”i noteicām, ka mēs nepamanÄ«jām nekādu izaugsmi kā tādu.

Tas galvenokārt ir saistÄ«ts ar faktu, ka sagatavoÅ”anās darbus sākām 2019. gada beigās. Tagad mÅ«su pakalpojumi ir rezervēti, tiek nodroÅ”ināta kļūdu tolerance fizisko serveru, virtualizācijas sistēmu, dokeru un tajos esoÅ”o pakalpojumu lÄ«menÄ«. Tajā paŔā laikā mÅ«su servera resursu jauda ļauj mums izturēt vairākas slodzes.

Galvenais instruments, kas mums palÄ«dzēja visā Å”ajā stāstā, bija mÅ«su uzraudzÄ«bas sistēma. Tiesa, vēl pavisam nesen mums nebija vienotas sistēmas, kas ļautu apkopot metriku visos slāņos, sākot no fiziskā aprÄ«kojuma un aparatÅ«ras lÄ«meņa lÄ«dz biznesa rādÄ«tāju lÄ«menim. 

Formāli uzņēmumā bija uzraudzÄ«ba, taču tā parasti bija izkliedēta un atradās konkrētu nodaļu atbildÄ«bas jomā. Faktiski, kad notika incidents, mums gandrÄ«z nekad nebija vienotas izpratnes par to, kas tieÅ”i noticis, nebija saziņas, un bieži tas noveda pie tā, ka skrējām riņķī, lai atrastu un izolētu problēmu, lai to varētu novērst.

Kādā brÄ«dÄ« mēs domājām un nolēmām, ka mums pietiek ar to izturēt - mums ir vajadzÄ«ga vienota sistēma, lai redzētu visu attēlu pilnÄ«bā. Galvenās tehnoloÄ£ijas, kas ir iekļautas mÅ«su kaudzē, ir Zabbix kā brÄ«dinājumu un metrikas glabāŔanas centrs, Prometheus lietojumprogrammu metrikas apkopoÅ”anai un glabāŔanai, Stack ELK datu reÄ£istrÄ“Å”anai un glabāŔanai no visas uzraudzÄ«bas sistēmas, kā arÄ« Grafana vizualizācijai, Swagger, Docker. un citas noderÄ«gas lietas, kas jums ir pazÄ«stamas.

Tajā paŔā laikā mēs izmantojam ne tikai tirgÅ« pieejamās tehnoloÄ£ijas, bet arÄ« izstrādājam dažas savas. Piemēram, mēs veidojam pakalpojumus sistēmu savstarpējai integrÄ“Å”anai, tas ir, sava veida API metrikas apkopoÅ”anai. Turklāt mēs strādājam pie savām uzraudzÄ«bas sistēmām ā€” biznesa metrikas lÄ«menÄ« mēs izmantojam lietotāja interfeisa testus. Un arÄ« bots Telegram, lai informētu komandas.

Mēs arÄ« cenÅ”amies padarÄ«t uzraudzÄ«bas sistēmu pieejamu komandām, lai tās varētu patstāvÄ«gi uzglabāt un strādāt ar saviem rādÄ«tājiem, tostarp iestatÄ«t brÄ«dinājumus dažiem Å”auriem rādÄ«tājiem, kas netiek plaÅ”i izmantoti. 

Visā sistēmā mēs tiecamies pēc proaktivitātes un incidentu lokalizācijas pēc iespējas ātrāk. Turklāt pēdējā laikā ievērojami pieaudzis mÅ«su mikropakalpojumu un sistēmu skaits, un attiecÄ«gi pieaudzis arÄ« integrāciju skaits. Un kā daļu no incidentu diagnostikas procesa optimizÄ“Å”anas integrācijas lÄ«menÄ« mēs izstrādājam sistēmu, kas ļauj veikt starpsistēmu pārbaudes un parādÄ«t rezultātu, kas ļauj atrast galvenās problēmas, kas saistÄ«tas ar importÄ“Å”anu un sistēmu mijiedarbÄ«bu ar viens otru. 

Protams, mums vēl ir kur augt un attÄ«stÄ«ties operētājsistēmu ziņā, un mēs pie tā aktÄ«vi strādājam. JÅ«s varat lasÄ«t vairāk par mÅ«su uzraudzÄ«bas sistēmu Å”eit

Tehniskās pārbaudes 

Orlovs Sergejs, tīmekļa un mobilās izstrādes kompetences centra vadītājs

KopÅ” fizisko veikalu slēgÅ”anas sākuma esam saskāruÅ”ies ar dažādiem izaicinājumiem no attÄ«stÄ«bas viedokļa. Pirmkārt, slodzes pieaugums kā tāds. Skaidrs, ka, ja netiek veikti atbilstoÅ”i pasākumi, tad sistēmai pieliekot lielu slodzi, tā ar bēdÄ«gu blÄ«kŔķi var pārvērsties par Ä·irbi vai pilnÄ«bā pasliktināties darbÄ«bā, vai pat zaudēt funkcionalitāti.

Otrs aspekts, kas ir nedaudz mazāk acÄ«mredzams, ir tas, ka sistēma ar lielu slodzi bija jāmaina ļoti ātri, pielāgojoties izmaiņām biznesa procesos. Dažreiz vairākas reizes dienā. Daudzos uzņēmumos ir noteikums, ka, ja ir daudz mārketinga aktivitāŔu, sistēmā nav jāveic nekādas izmaiņas. Nekāds, ļaujiet tam darboties tik ilgi, kamēr tas darbojas.

Un mums būtībā bija nebeidzama Melnā piektdiena, kuras laikā bija jāmaina sistēma. Un jebkura kļūda, problēma vai kļūme sistēmā uzņēmumam izmaksātu ļoti dārgi.

Raugoties uz priekÅ”u, teikÅ”u, ka ar Å”iem testiem mums izdevās tikt galā, visas sistēmas izturēja slodzi, bija viegli mērogojamas, un globālas tehniskas kļūmes nepiedzÄ«vojām.

Ir četri balsti, uz kuriem balstās sistēmas spēja izturēt lielas pārsprieguma slodzes. Pirmais no tiem ir uzraudzÄ«ba, par kuru jÅ«s lasÄ«jāt tieÅ”i iepriekÅ”. Bez iebÅ«vētas uzraudzÄ«bas sistēmas ir gandrÄ«z neiespējami atrast sistēmas vājās vietas. Laba uzraudzÄ«bas sistēma ir kā mājas apģērbs; tai jābÅ«t ērtai un pielāgotai jums.

Otrs aspekts ir pārbaude. Mēs Å”o punktu uztveram ļoti nopietni: katrai sistēmai rakstām klasiskās vienÄ«bas, integrācijas testus, slodzes testus un daudz ko citu. Mēs arÄ« rakstām testÄ“Å”anas stratēģiju un tajā paŔā laikā cenÅ”amies paaugstināt testÄ“Å”anas lÄ«meni lÄ«dz tādam lÄ«menim, ka mums vairs nav vajadzÄ«gas manuālas pārbaudes.

TreÅ”ais pÄ«lārs ir CI/CD cauruļvads. Lietojumprogrammas izveides, testÄ“Å”anas un izvietoÅ”anas procesiem jābÅ«t pēc iespējas automatizētiem; nevajadzētu veikt manuālu iejaukÅ”anos. CI/CD Pipeline tēma ir diezgan dziļa, un es tai pieskarÅ”os tikai Ä«si. Ir tikai vērts pieminēt, ka mums ir CI/CD Pipeline kontrolsaraksts, kuru katra produktu komanda iziet ar kompetenču centru palÄ«dzÄ«bu.

Kas palÄ«dzēja mums ātri pielāgoties tieÅ”saistes tirdzniecÄ«bai jaunajos apstākļosUn Å”eit ir kontrolsaraksts

Tādā veidā tiek sasniegti daudzi mērÄ·i. Å Ä« ir API versiju noteikÅ”ana un funkciju pārslēgÅ”ana, lai izvairÄ«tos no izlaiÅ”anas un dažādu testu pārklājuma sasniegÅ”anas tādā lÄ«menÄ«, ka testÄ“Å”ana ir pilnÄ«bā automatizēta, izvietoÅ”ana ir nemanāma utt.

Ceturtais pīlārs ir arhitektūras principi un tehniskie risinājumi. Par arhitektūru mēs varam runāt daudz un ilgi, bet es gribu uzsvērt pāris principus, uz kuriem es vēlētos pievērsties.

Pirmkārt, jums ir jāizvēlas specializēti rÄ«ki konkrētiem uzdevumiem. Jā, tas izklausās paÅ”saprotami, un skaidrs, ka ar āmuru jādzen naglas, bet rokas pulksteņi jāizjauc ar speciāliem skrÅ«vgriežiem. Bet mÅ«su laikmetā daudzi rÄ«ki tiecas pēc universalizācijas, lai aptvertu maksimālo lietotāju segmentu: datu bāzes, keÅ”atmiņas, ietvari un pārējo. Piemēram, ja izmantojat MongoDB datu bāzi, tā darbojas ar vairāku dokumentu transakcijām, un Oracle datu bāze darbojas ar json. Un Ŕķiet, ka visu var izmantot visam. Bet, ja mēs iestājamies par produktivitāti, tad mums ir skaidri jāsaprot katra rÄ«ka stiprās un vājās puses un jāizmanto tie, kas nepiecieÅ”ami mÅ«su uzdevumu klasei. 

Otrkārt, projektējot sistēmas, katrs sarežģītÄ«bas pieaugums ir jāpamato. Mums tas pastāvÄ«gi jāpatur prātā, zemās sakabes princips ir zināms visiem. Es uzskatu, ka tas ir jāpiemēro gan konkrēta pakalpojuma lÄ«menÄ«, gan visas sistēmas lÄ«menÄ«, gan arhitektÅ«ras ainavas lÄ«menÄ«. SvarÄ«ga ir arÄ« iespēja horizontāli mērogot katru sistēmas komponentu slodzes ceļā. Ja jums ir Ŕī spēja, mērogoÅ”ana nebÅ«s grÅ«ta.

Runājot par tehniskajiem risinājumiem, mēs lūdzām produktu komandas sagatavot jaunu ieteikumu, ideju un risinājumu kopumu, ko tās īstenoja, gatavojoties nākamajam slodzes vilnim.

KeŔi

Ir nepiecieÅ”ams apzināti pievērsties lokālo un izplatÄ«to keÅ”atmiņu izvēlei. Dažreiz ir jēga izmantot abus vienā sistēmā. Piemēram, mums ir sistēmas, kurās daži dati bÅ«tÄ«bā ir keÅ”atmiņa, tas ir, atjauninājumu avots atrodas aiz paÅ”as sistēmas un sistēmas nemainās. Å”ie dati. Å ai pieejai mēs izmantojam vietējo kofeÄ«na keÅ”atmiņu. 

Un ir dati, ka sistēma darbÄ«bas laikā aktÄ«vi mainās, un Å”eit mēs jau izmantojam izplatÄ«to keÅ”atmiņu ar Hazelcast. Å Ä« pieeja ļauj mums izmantot izkliedētās keÅ”atmiņas priekÅ”rocÄ«bas tur, kur tās patieŔām ir vajadzÄ«gas, un samazināt pakalpojumu izmaksas, kas saistÄ«tas ar Hazelcast klasteru datu cirkulāciju, kur mēs varam iztikt bez tā. Mēs esam daudz rakstÄ«juÅ”i par keÅ”atmiņām. Å”eit Šø Å”eit.

Turklāt serializatora nomaiņa uz Kryo programmā Hazelcast deva mums labu stimulu. Un pāreja no ReplicatedMap uz IMap + Near Cache pakalpojumā Hazelcast ļāva mums samazināt datu kustÄ«bu klasterÄ«. 

Neliels padoms: masveida keÅ”atmiņas nederÄ«guma gadÄ«jumā dažreiz ir piemērojama taktika iesildÄ«t otro keÅ”atmiņu un pēc tam pārslēgties uz to. Å Ä·iet, ka ar Å”o pieeju vajadzētu iegÅ«t dubultu atmiņas patēriņu, taču praksē tajās sistēmās, kurās tas tika praktizēts, atmiņas patēriņŔ samazinājās.

Reaktīvā kaudze

Mēs izmantojam reaktÄ«vo steku diezgan daudzās sistēmās. MÅ«su gadÄ«jumā tas ir Webflux vai Kotlin ar korutÄ«nām. ReaktÄ«vā kaudze ir Ä«paÅ”i laba, ja mēs sagaidām lēnas ievades-izejas darbÄ«bas. Piemēram, zvani uz lēniem pakalpojumiem, darbs ar failu sistēmu vai uzglabāŔanas sistēmām.

VissvarÄ«gākais princips ir izvairÄ«ties no zvanu bloÄ·Ä“Å”anas. ReaktÄ«vajos ietvaros ir neliels skaits tieÅ”o pakalpojumu pavedienu, kas darbojas zem pārsega. Ja mēs bezrÅ«pÄ«gi ļausim sev veikt tieÅ”u bloÄ·Ä“Å”anas zvanu, piemēram, JDBC draivera zvanu, sistēma vienkārÅ”i apstāsies. 

Mēģiniet kļūdas pārvērst par savu izpildlaika izņēmumu. Faktiskā programmas izpildes plÅ«sma pāriet uz reaktÄ«viem ietvariem, un koda izpilde kļūst nelineāra. Tā rezultātā ir ļoti grÅ«ti diagnosticēt problēmas, izmantojot steka pēdas. Un risinājums Å”eit bÅ«tu izveidot skaidrus, objektÄ«vus izpildlaika izņēmumus katrai kļūdai.

Elastikas meklēŔana

Izmantojot Elasticsearch, neatlasiet neizmantotos datus. Tas principā ir arÄ« ļoti vienkārÅ”s padoms, bet visbiežāk tas tiek aizmirsts. Ja jums ir jāatlasa vairāk nekā 10 tÅ«kstoÅ”i ierakstu vienlaikus, jums ir jāizmanto Scroll. Lai izmantotu analoÄ£iju, tas ir mazliet kā kursors relāciju datu bāzē. 

Neizmantojiet pēcfiltru, ja vien tas nav nepiecieÅ”ams. Ja galvenajā paraugā ir lieli dati, Ŕī darbÄ«ba ievērojami noslogo datu bāzi. 

Attiecīgā gadījumā izmantojiet lielapjoma darbības.

API

Izstrādājot API, iekļaujiet prasÄ«bas pārsÅ«tÄ«to datu samazināŔanai. Tas jo Ä«paÅ”i attiecas uz priekŔējo daļu: tieÅ”i Å”ajā krustojumā mēs pārsniedzam mÅ«su datu centru kanālus un jau strādājam pie kanāla, kas savieno mÅ«s ar klientu. Ja tam ir vismazākā problēma, pārāk liela trafika rada negatÄ«vu lietotāja pieredzi.

Un visbeidzot, neizmetiet daudz datu, skaidri norādiet līgumu starp patērētājiem un piegādātājiem.

Organizatoriskā transformācija

Eroshkina Jeļena, direktora vietniece IT jautājumos

BrÄ«dÄ«, kad iestājās karantÄ«na un radās nepiecieÅ”amÄ«ba strauji palielināt tieÅ”saistes attÄ«stÄ«bas tempus un ieviest daudzkanālu pakalpojumus, mēs jau bijām organizācijas transformācijas procesā. 

Daļa no mÅ«su struktÅ«ras tika nodota darbam saskaņā ar produkta pieejas principiem un praksi. Ir izveidotas komandas, kas tagad ir atbildÄ«gas par katra produkta darbÄ«bu un attÄ«stÄ«bu. Darbinieki Ŕādās komandās ir 100% iesaistÄ«ti un strukturē savu darbu, izmantojot Scrum vai Kanban, atkarÄ«bā no tā, kas viņiem ir labāks, izvietoÅ”anas cauruļvada izveidoÅ”ana, tehniskās prakses ievieÅ”ana, kvalitātes nodroÅ”ināŔanas prakse un daudz kas cits.

Paveicās, ka lielākā daļa mÅ«su produktu komandu bija tieÅ”saistes un daudzkanālu pakalpojumu jomā. Tas ļāva mums pēc iespējas Ä«sākā laikā (nopietni, burtiski divu dienu laikā) pārslēgties uz attālā darba režīmu, nezaudējot efektivitāti. Pielāgotais process ļāva mums ātri pielāgoties jauniem darba apstākļiem un uzturēt diezgan augstu jaunu funkcionalitātes piegādes tempu.

Turklāt mums ir jāstiprina tās komandas, kas atrodas tieÅ”saistes biznesa priekÅ”galā. Tajā brÄ«dÄ« kļuva skaidrs, ka mēs to varam izdarÄ«t tikai izmantojot iekŔējos resursus. Un aptuveni 50 cilvēki divu nedēļu laikā mainÄ«ja jomu, kurā viņi strādāja iepriekÅ”, un iesaistÄ«jās darbā pie produkta, kas viņiem bija jauns. 

Tas neprasÄ«ja Ä«paÅ”as vadÄ«bas pÅ«les, jo lÄ«dztekus sava procesa organizÄ“Å”anai, produkta tehniskajai pilnveidoÅ”anai un kvalitātes nodroÅ”ināŔanas praksēm, mēs mācām mÅ«su komandām paÅ”organizēties ā€“ vadÄ«t savu ražoÅ”anas procesu, neiesaistot administratÄ«vos resursus.

Mēs varējām fokusēt savus vadÄ«bas resursus tieÅ”i tur, kur tas tajā brÄ«dÄ« bija nepiecieÅ”ams ā€“ koordinācijai kopā ar biznesu: Kas mÅ«su klientam Å”obrÄ«d ir svarÄ«gi, kāda funkcionalitāte jāievieÅ” vispirms, kas jādara, lai palielinātu caurlaides spēju. lai piegādātu un apstrādātu pasÅ«tÄ«jumus. Tas viss un skaidrs paraugs ļāva Å”ajā periodā mÅ«su produkcijas vērtÄ«bu plÅ«smas noslogot ar to, kas patieŔām ir svarÄ«gs un vajadzÄ«gs. 

Skaidrs, ka ar attālinātu darbu un lielu pārmaiņu tempu, kad biznesa rādÄ«tāji ir atkarÄ«gi no katra lÄ«dzdalÄ«bas, nevar paļauties tikai uz iekŔējām sajÅ«tām no sērijas ā€œVai mums viss iet labi? Jā, Ŕķiet labi.ā€ Ir nepiecieÅ”ami objektÄ«vi ražoÅ”anas procesa rādÄ«tāji. Mums tādi ir, tie ir pieejami ikvienam, kam interesē produktu komandu rādÄ«tāji. Pirmkārt, pati komanda, bizness, apakÅ”uzņēmēji un vadÄ«ba.

Reizi divās nedēļās katrai komandai tiek noteikts statuss, kurā 10 minÅ«tes tiek analizēti rādÄ«tāji, tiek identificētas ražoÅ”anas procesa vājās vietas un tiek izstrādāts kopÄ«gs risinājums: ko darÄ«t, lai Ŕīs nepilnÄ«bas novērstu. Å eit jÅ«s varat nekavējoties lÅ«gt palÄ«dzÄ«bu vadÄ«bai, ja kāda identificēta problēma ir ārpus komandu ietekmes zonas, vai arÄ« kolēģu zināŔanas, kuri, iespējams, jau ir saskāruÅ”ies ar lÄ«dzÄ«gu problēmu.

Tomēr mēs saprotam, ka, lai paātrinātu vairākas reizes (un tieÅ”i Ŕādu mērÄ·i mēs sev izvirzām), mums joprojām ir daudz jāmācās un jāievieÅ” savā ikdienas darbā. Å obrÄ«d mēs turpinām paplaÅ”ināt savu produktu pieeju citām komandām un jauniem produktiem. Lai to izdarÄ«tu, mums bija jāapgÅ«st jauns formāts - tieÅ”saistes metodiÄ·u skola.

Metodologi, cilvēki, kas palÄ«dz komandām izveidot procesu, izveidot komunikāciju un uzlabot darba efektivitāti, bÅ«tÄ«bā ir pārmaiņu aÄ£enti. Å obrÄ«d mÅ«su pirmās kohortas absolventi strādā ar komandām un palÄ«dz tām gÅ«t panākumus. 

Domāju, ka esoŔā situācija mums paver tādas iespējas un perspektÄ«vas, kuras varbÅ«t mēs paÅ”i vēl lÄ«dz galam neapzināmies. Taču Å”obrÄ«d uzkrātā pieredze un prakse apliecina, ka esam izvēlējuÅ”ies pareizo attÄ«stÄ«bas ceļu, Ŕīs jaunās iespējas nepalaidÄ«sim garām arÄ« turpmāk un spēsim tikpat efektÄ«vi reaģēt uz izaicinājumiem, ar kuriem saskarsies Sportmaster.

Atzinumi

Å ajā grÅ«tajā laikā esam formulējuÅ”i galvenos principus, uz kuriem balstās programmatÅ«ras izstrāde, kas, manuprāt, bÅ«s aktuāli katram uzņēmumam, kas ar to nodarbojas.

Cilvēki. Uz to viss balstās. Darbiniekiem ir jābauda savs darbs un jāsaprot uzņēmuma mērÄ·i un to produktu mērÄ·i, pie kuriem viņi strādā. Un, protams, viņi varēja profesionāli attÄ«stÄ«ties. 

Š¢ŠµŃ…Š½Š¾Š»Š¾Š³Šøя. Uzņēmumam ir jāizmanto nobriedusi pieeja darbam ar savu tehnoloÄ£iju kopumu un jāveido kompetences tur, kur tas patieŔām ir nepiecieÅ”ams. Tas izklausās ļoti vienkārÅ”i un acÄ«mredzami. Un ļoti bieži ignorē.

Procesi. Ir svarīgi pareizi organizēt produktu komandu un kompetences centru darbu, veidot mijiedarbību ar uzņēmumu, lai strādātu ar to kā partneri.

Kopumā tā mēs izdzÄ«vojām. MÅ«su laika galvenā tēze vēlreiz apstiprinājās, ar skaļu klikŔķi uz pieres

Pat ja jums ir milzÄ«gs bezsaistes uzņēmums ar daudziem veikaliem un daudzām pilsētām, kurās strādājat, attÄ«stiet savu tieÅ”saistes biznesu. Tas nav tikai papildu pārdoÅ”anas kanāls vai skaista aplikācija, caur kuru var arÄ« kaut ko iegādāties (un arÄ« tāpēc, ka konkurentiem arÄ« ir skaisti). Å Ä« nav tikai gadÄ«jumam paredzēta rezerves riepa, kas palÄ«dzēs izturēt vētru.

Tā ir absolÅ«ta nepiecieÅ”amÄ«ba. Kam jāsagatavo ne tikai savas tehniskās iespējas un infrastruktÅ«ra, bet arÄ« jÅ«su cilvēki un procesi. Galu galā pāris stundu laikā jÅ«s varat ātri iegādāties papildu atmiņu, vietu, izvietot jaunus gadÄ«jumus utt. Bet cilvēki un procesi tam ir jāsagatavo jau iepriekÅ”.

Avots: www.habr.com

Pievieno komentāru