Kultūra dažnai ignoruojama ir neteisingai suprantama, tačiau tai yra pagrindinis veiksnys, lemiantis įmonės veiklą. Jei netvarkysime savo kultūros, galų gale atliksime neteisingą praktiką, kuri galiausiai paveiks mūsų verslo tikslus.
Dabartinės organizacijos kultūros supratimas
Kultūra pasakoja apie grupės ar įmonės vertybes ir normas. Joje nurodoma, kas svarbu, taip pat kaip žmonės artėja ir dirba tarpusavyje.
KULTŪRA = „Kaip viskas gali būti padaryta protingai, norint sėkmės“
Paimkime klientų palaikymo komandos pavyzdį. Šios komandos kultūra turėtų būti tokia, kad galų gale jie pasiektų 97-98% klientų pasitenkinimo.
Turint omenyje kliento džiaugsmą, pirmiausia jie turi būti mandagūs, net ir sunkiose situacijose jie turi būti geri klausytojai, kad išvengtų painiavos, kad darbui turėtų būti teikiama pirmenybė pagal reikalavimus.
Trumpam stabtelėkime ir užduokime sau keletą klausimų:
- Kokia mano įmonės kultūra dabar?
- Kaip ši kultūra derinama su mano verslo tikslais ar KRA?
- Kokių problemų galiu tikėtis dėl neatitikimo?
Kiekvienai organizacijai 4C atlieka svarbų vaidmenį
Pažvelkime į programinę įrangą kuriančios organizacijos kultūrą. Yra daug komandų, kurios kuria ir palaiko vieną programinės įrangos bloką. Visos šios komandos turi atskirus tikslus ir atskirą kultūrą.
Šis procesas prasideda po to, kai klientas patvirtina reikalavimus.
Kūrėjai vadovaujasi savo organizacijos apibrėžtomis kodavimo gairėmis, o kodui generuoti naudojami programavimo įrankiai, pvz., Kompiliatoriai, vertėjai, derintojai ir kt. Kodavimui naudojamos skirtingos aukšto lygio programavimo kalbos, tokios kaip C, C ++, Pascal, Java ir PHP.
Jie padalija visą paketą į mažus aplankus ir tada atitinkamai sukuria mažus kodus.
1 etapas : Tada šie nedideli kodų vienetai suformuojami dideliu vienetu. Integruojant mažesnes mikroschemas, reikia atlikti projekto lygio testavimą, vadinamą integravimo bandymu.
2 etapas : Po sėkmingos integracijos jis įdiegiamas į manekeno sistemą. Ši manekeno sistema turi panašią konfigūraciją kaip kliento mašina arba mašina, kurioje šis projektas turi būti galutinai įdiegtas.
3 etapas : Galiausiai, išbandžius visas manekeno sistemos funkcijas, projektas diegiamas gamybos serveryje arba kliento mašinoje.
Nors atrodo, kad šis procesas yra labai sklandus ir lengvas žodžiais, techniškai jį pasiekti yra labai sunku.
Pažiūrėkime, su kokiomis problemomis galime susidurti:
kaip spausdinti masyvo php
1 etapas :
Klientas visada ieško pokyčių, kad pagerintų produkto kokybę. Dažniausiai, kai buvo padaryta pirmoji kartojimas, klientas pasiūlys keletą pakeitimų. Kai kūrėjai gauna pakeitimus, jie pradeda juos įtraukti, o tai daro įtaką integracijai, kuri sukelia sugadintą kūrimą.
2 etapas:
Dažniausiai bandytojai ar kiti operacijos vaikinai nežinos apie naujus pakeitimus, kuriuos reikia atlikti. Kai tik gauna kodą iš kūrėjų, jie pradeda juos testuoti. Kūrėjai vis dar atlieka pakeitimus.
Kadangi jie negauna pakankamai laiko naujiems pakeitimams įgyvendinti, jie sukuria neefektyvius kodus, su kuriais susiduria su kitomis tinklo ir duomenų bazių problemomis, o tai vėluoja jų pristatymo laiką.
Kai jie pagaliau pateikia kodus operacijų komandai, jiems lieka labai mažai laiko sukurti ir įgyvendinti naujus bandymo atvejus. Taigi jie praleidžia daugelį bandomųjų atvejų, kuriuos vėliau supranta, kad jie buvo svarbiausi.
3 etapas:
Nors atrodo, kad sukūrimas yra pasirengęs pradėti gaminti, tačiau rezultatai yra visiškai netikėti. Sukurti nepavyksta ir įvyksta daugybė klaidų.
Tada kiekvienai klaidai jie turi sekti, kodėl tai įvyko, kur ji įvyko, kokius pakeitimus reikia atlikti, norint ją įveikti, ar pasikeis kitų kodai, kad jis būtų suderinamas su ankstesniais. Galiausiai, dėl visų šių klaidų, reikia sukurti klaidų ataskaitą.
Gedimas įvyko dėl sistemos klaidų, susijusių su duomenų bazės kūrėjo nežinojimu apie kodo efektyvumą, bandytojo nežinojimu bandymų atvejų skaičiumi ir kt.
Kadangi klientas visada laikosi griežtų terminų, darbuotojai, dalyvaujantys jų siekime, paskutiniame leidime sutelkia dėmesį tik tuo atveju, jei jie turi pakenkti bendrai kokybei.
Nors atrodo, kad tai yra darbo koordinavimo problema, tai iš tikrųjų yra priimtos kultūros nesėkmė.
Tai atsitinka dėl didelės priklausomybės nuo rankinių procesų. Bėgimas pirmyn ir atgal toje pačioje komandoje, nes trūksta žinių apie skirtingas sritis, trūksta prieigos arba gali būti nesidomėjimas padidina mūsų pačių naštą ir skausmą.
Atėjo laikas, kad būtume universalūs. Gali būti sunku valdyti visus sistemoje vykstančius procesus, tačiau mes galime būti visų domkratas, įvaldyti vieną iš jų. Tada tik mes galime automatizuoti savo sistemą arba padaryti ją pakankamai protingą, kad atsigautume, o ne grįžtame atgal.
Dabar tu gali galvoti, kodėl?
Taip yra todėl, kad tas, kurį tu valdai, labai priklauso nuo kitų. Taigi, norėdami sužinoti apie priklausomybės tašką, turime suprasti visą sistemą.
Taigi pagalvokime apie kultūros keitimo procesą. Prieš tai turite atsakymą į žemiau pateiktus klausimus?
- Kur žlunga dabartinė jūsų kultūra?
- Kodėl norite pakeisti procesą?
- Ar aiškiai nustatėte visus būtinus pakeitimus?
- Ar gavote visų nukentėjusiųjų suinteresuotųjų šalių atsiliepimų ir pirkimų?
- Ar pakartojote proceso discipliną, duomenų ir matavimo sistemos pakeitimus?
Taigi, dabar, kai turime atsakymą į visus, galvojame apie savo sistemos revoliuciją. Kaip vyks ši revoliucija? Tai galima pasiekti tik tada, kai nužudome tai, kas esame dabar. Daug laiko sugaišta kodų perkėlimui tarp komandų. Turime pristatyti procesą, kuriame galėtume atlikti nuolatinę integraciją ir nuolatinį diegimą.
Šis nuolatinės integracijos ir diegimo procesas daro jį judresnį. Šio judrumo suteikimas laikomas „DevOps“ kultūra.
„DevOps“ yra operacijų ir kūrimo inžinierių, dalyvaujančių kartu per visą paslaugų gyvavimo ciklą, nuo projektavimo iki kūrimo proceso iki gamybos palaikymo, praktika.
kaip rasti didžiausią skaičių masyvo Java
Laikui bėgant pakeisti darbo sistemą nėra lengva. Sėkmingas perėjimas yra sistemos atnaujinimas, o ne atstatymas.
Dabar pažiūrėkime, kaip mes galime tai pasiekti. Galima kreiptis dviem būdais.
1) Iš viršaus į apačią
pitonas kas yra __init__
2) iš apačios į viršų
Pasinerdami į šias technikas, suprasime, kas geriausiai tinka mūsų organizacijai.
Taikydami metodą „iš viršaus į apačią“ galime kreiptis į aukštesnįjį vadovybę ir paprašyti, kad jie atliktų pakeitimus visose komandose. Jei tada vadovybė yra įsitikinusi, galime pradėti tai dirbti.
Tačiau tikimybė gauti atsakymą kaip „NE“ yra gana didelė. Taip yra todėl, kad pakeitus sistemą organizacija gali patekti į nestabilumą.
Jie turi pasidomėti organizacijos struktūra, pajamomis, kliento interesų lygiu ir pan. Tačiau svarbiausias faktorius, kuris juos traukia išstumti iš senosios sistemos, yra tai, kad jie nemato didelis vaizdas, ką galima pasiekti ir kaip sklandžiai tai galima pasiekti naudojant naujesnį.
Šiuo atveju galime ieškoti antrojo požiūrio, kad gautume šį bendrą vaizdą.
Metodas „iš apačios į viršų“ reikalauja savanorių. Čia mes turime paimti nedidelę komandą ir nedidelę užduotį ir ją atlikti „DevOps Model“.
Žvelgiant į techninę šio modelio pusę, mes turime įvairių sudėtingų įrankių rinkinį, kuris padaro darbą efektyvesnį ir greitesnį. Tačiau vien įrankiai nėra pakankamai pajėgūs sukurti bendradarbiavimo aplinką, vadinamą „DevOps“.
Kuriant tokią aplinką reikia galvoti ne iš dėžės, pvz. įvertinti ir pertvarkyti, kaip žmonės galvoja apie savo komandas, verslą ir klientus.
Naujų priemonių rinkinį sudaryti yra paprasčiau nei pakeisti organizacijos kultūrą. Reklamuodami antisocialius pagrindinius kūrėjus, leisdami integruoti neefektyvius kodus, netinkamai patikrintus kodus, kaltindami vienas kitą, manydami, kad operacijų komanda yra kvaila, nėra geriausia praktika, kurios mes laikomės, kad verslas būtų įgalintas. ir sukurti vertę mūsų klientams.
Procesą komplikuoja ne priemonės, o juos naudojantys žmonės. Pasakymas abstrakčiu lygmeniu, o ne idėjų ir elgesio rinkimas, atvirumas jiems nukelia į šviesų kelią.
Pradėkime nuo 6 narių komandos ir 3 taškų istorijos. Pirmiausia turime suskaidyti komandą, kurią vadiname kūrėjais, operacijomis, testuotojais ir tt. Mes juos visus laikome vienu, sakykime „DevOps“. Gavę reikalavimus turime išanalizuoti rizikos zonas. Turėdami omenyje gilesnius jūros & hellip ruožus .. Pradedame plaukioti.
Dabar jūs turite galvoti „koks yra šios nuolatinės integracijos ir nuolatinio diegimo x faktorius, mažinantis gedimo tikimybę“.
Patobulinę viziją ir procesą, mes galime kreiptis į vadovybę, pateikdami aiškų rezultatų vaizdą, pavyzdžiui, koks sklandus buvo procesas, kaip sumažėjo nesėkmės rizika, kaip užduotis buvo atlikta prieš laiko juostą ir kt.
Dabar mes galime aiškiai įsivaizduoti, kaip visas procesas buvo optimizuotas techninėje ir kultūrinėje aplinkoje, retrospektyviai atlikus kiekvieną kartojimą.
„Edureka“ specialiai kuravo tai padeda jums įsisavinti tokias lėlių, Jenkins, Ansible, SaltStack, Chef koncepcijas.
Turite mums klausimą? Paminėkite juos komentarų skiltyje ir mes susisieksime su jumis.
Susijusios žinutės: