Kultur blir ofte ignorert og misforstått, men likevel er det en nøkkelfaktor som er ansvarlig for selskapets resultater. Hvis vi ikke forvalter kulturen vår, vil vi ende opp med å gjøre feil praksis som til slutt vil påvirke forretningsmålene våre.
Forstå gjeldende kultur i en organisasjon
Kultur forteller oss om verdiene og normene i en gruppe eller bedrift. Den identifiserer hva som er viktig, samt hvordan folk nærmer seg og jobber med hverandre.
KULTUR = “Hvordan ting kan gjøres smart for å lykkes”
La oss ta eksemplet med et kundesupportteam. Kulturen til teamet skal være slik at de ender med å oppnå 97-98% av kundetilfredsheten.
Når kundene gleder seg, trenger de først og fremst å være høflige, selv i vanskelige situasjoner må de være gode lyttere for å unngå forvirring, de trenger å prioritere arbeidet i henhold til kravet.
La oss ta en pause og stille noen spørsmål til oss selv:
- Hva er kulturen i selskapet mitt nå?
- Hvor godt er denne kulturen i samsvar med mine forretningsmål eller KRA?
- Hvilke problemer kan jeg forvente på grunn av feiljustering?
For hver organisasjon spiller 4C-ene en viktig rolle
konvertere fra dobbelt til int java
La oss nå se på kulturen til en programvareutviklende organisasjon. Det er mange team involvert for å bygge og vedlikeholde en enkelt programvareenhet. Alle disse lagene har separate mål og egen kultur.
Denne prosessen starter etter at kravene er bekreftet av klienten.
Utviklere følger retningslinjene for koding definert av deres organisasjon og programmeringsverktøy som kompilatorer, tolker, feilsøkere osv. Brukes til å generere koden. Forskjellige programmeringsspråk på høyt nivå som C, C ++, Pascal, Java og PHP brukes til koding.
De deler den komplette pakken i små mapper og utvikler deretter små koder deretter.
1. stadie : Disse små kodenehetene blir deretter klumpet sammen for å danne en stor enhet. Mens du integrerer de mindre sjetongene, må en test på prosjektnivå utføres, kjent som integrasjonstesting.
Trinn 2 : Etter vellykket integrering blir den distribuert i et dummy-system. Dette dummy-systemet har lignende konfigurasjon som klientmaskinen eller maskinen der dette prosjektet endelig må distribueres.
Trinn 3 : Til slutt, etter å ha testet alle funksjonene i et dummy-system, distribueres prosjektet på produksjonsserveren eller klientmaskinen.
Selv om denne prosessen ser ut til å være veldig jevn og enkel i ord, er den teknisk vanskelig å oppnå.
La oss se hvilke problemer vi kan møte:
1. stadie :
Kunden er alltid på jakt etter endringer for å forbedre kvaliteten på produktet. Mesteparten av tiden da den første iterasjonen ble gjort, vil klienten foreslå noen få endringer. Når utviklerne mottar endringene, begynner de å innlemme dem som påvirker integrasjonen som fører til ødelagte bygg.
Fase 2:
Det meste av tiden vil ikke testere eller andre operasjonsgutter være klar over de nye endringene som skal gjøres. Så snart de får koden fra utviklere, begynner de å teste dem. Mens de er på baksiden, gjør utviklerne fremdeles endringene.
Siden de ikke får nok tid til å implementere nye endringer, ender de opp med å utvikle ineffektive koder de møter andre nettverks- og databaseproblemer som igjen forsinker leveringstiden.
Når de endelig leverer kodene til operasjonsteamet, har de veldig liten tid til å lage og implementere nye testsaker. Så de hopper over mange av testsakene som de senere innser at de hadde høy prioritet.
Trinn 3:
Selv om praktisk talt bygningen ser ut til å være klar til produksjon, men resultatene er helt uventede. Bygningen mislykkes, og det oppstår en rekke feil.
Så for hver feil som oppstod, må de spore hvorfor det skjedde, hvor det skjedde, hvilke endringer som må gjøres for å overvinne det, blir det endring i andres koder for å gjøre det kompatibelt med de forrige. Til slutt, for alle disse feilene, må det genereres en feilrapport.
Feilen skyldes systemfeil på grunn av databaseutviklerens uvitenhet om kodens effektivitet, testers uvitenhet i antall testsaker osv.
Siden klienten alltid holder tidsfristen, konsentrerer de ansatte som er involvert i å oppnå dem bare i den endelige utgivelsen, selv om de må gå på akkord med den generelle kvaliteten.
Selv om dette ser ut til å være et problem i koordinering av arbeidet, dette er faktisk fiaskoen i den adopterte kulturen.
Dette skjer på grunn av stor avhengighet av manuelle prosesser. Å løpe frem og tilbake i samme team på grunn av manglende kunnskap om forskjellige felt manglende tilgang eller mangel på interesse øker vår egen byrde og smerte.
Det er på høy tid at vi trenger å være allsidige. Det kan være vanskelig å være mestrer i alle prosesser som er involvert i et system, men vi kan være knekt for alle og mestre en av dem. Da er det bare vi som kan automatisere systemet vårt eller gjøre det intelligent nok til å gjenopprette i stedet for tilbakeslag.
Nå tenker du kanskje hvorfor?
oppslagstransformasjon i informatica eksempel
Det er fordi den du mestrer er veldig avhengig av andre. Så for å vite om avhengighetspunktet, må vi forstå hele systemet.
Så la oss tenke på en prosess for å endre kulturen. Før det har du svaret på spørsmålene nedenfor?
- Hvor mislykkes din nåværende kultur?
- Hvorfor ønsker du å endre prosessen?
- Har du tydelig identifisert alle nødvendige endringer?
- Har du fått tilbakemelding og innkjøp fra alle berørte interessenter?
- Har du revalidert prosessdisiplin, data og målesystem for endringen?
Så når vi har svaret til alle, tenker vi på en revolusjon i systemet vårt. Hvordan vil denne revolusjonen finne sted? Det kan bare oppnås når vi dreper det vi er nå. Mye tid er bortkastet i overføring av kode blant lagene. Vi må bringe prosessen der vi kan gjøre kontinuerlig integrering og kontinuerlig distribusjon.
Denne prosessen med kontinuerlig integrering og distribusjon gjør den mer smidig. Å bringe denne smidigheten anses å være DevOps-kultur.
DevOps er praksis for drifts- og utviklingsingeniører som deltar sammen i hele tjenestens livssyklus, fra design gjennom utviklingsprosessen til produksjonsstøtte.
Det er ikke lett å endre arbeidssystemet over tid. Å gjøre en vellykket overgang er å renovere systemet, i stedet for å gjenoppbygge.
La oss nå se hvordan vi kan oppnå dette. Det kan være to måter å nærme seg på.
lagringsklasser i c ++
1) Topp opp og ned
2) Nederst opp
Dykker vi dypere inn i disse teknikkene, vil vi innse hvilke som passer best for organisasjonen vår.
I ovennevnte tilnærming kan vi gå til den høyere ledelsen og be dem om å gjøre endringer på tvers av alle lagene. Hvis ledelsen er overbevist da, kan vi begynne å jobbe med det.
Men sannsynligheten for å få svaret som 'NEI' er ganske høy. Det er fordi endring av systemet kan føre organisasjonen til ustabilitet.
De må se på organisasjonsstrukturen, inntektene, klientens rentenivå osv. Men den viktigste faktoren som trekker dem tilbake fra å gå ut av det gamle systemet er at de ikke kan se stort bilde av hva som kan oppnås og hvor jevnt det kan oppnås med den nyere.
I dette tilfellet kan vi se etter den andre tilnærmingen for å få dette store bildet.
Bunn-opp-tilnærmingen krever frivillig arbeid. Her må vi ta et lite team og en liten oppgave og utføre det i DevOps Model.
Når vi ser på den tekniske siden av denne modellen, har vi forskjellige sett med sofistikerte verktøy som gjør arbeidet mer effektivt og raskt. Men verktøy alene er ikke i stand til å skape et samarbeidsmiljø referert til som DevOps.
Å skape et slikt miljø krever at du tenker ut av boksen f.eks. vurdere og omstille hvordan folk tenker på teamene sine, virksomheten og kundene.
Å sette sammen et nytt sett med verktøy er enklere enn å endre organisasjonskulturen. Ved å promotere de antisosiale hovedutviklerne, la ineffektiv kode integreres, distribuere koder som ikke ble testet ordentlig, sette skylden på hverandres hode, og vurdere operasjonsteamet som dumt, er ikke den beste fremgangsmåten vi følger for å aktivere virksomheten og skape verdi for våre kunder.
Det er ikke verktøyene, det er menneskene som bruker dem som gjør prosessen komplisert. Å si på et abstrakt nivå i stedet for å samle ideer og atferd, å være åpen for dem tar oss til en lys vei.
La oss starte med et team på 6 medlemmer og en 3-punkts historie. Først må vi bryte teamet vi kaller som utviklere, operasjoner, testere osv. Vi ser på dem alle som ett, si 'DevOps'. Når vi mottar kravene, må vi analysere risikosonene. Husk de dypere delene av havet og hellip .. Vi begynner å seile.
Nå må du tenke 'hva er x-faktoren til denne kontinuerlige integrasjonen og kontinuerlige distribusjonen som reduserer sannsynligheten for feil'.
Med den forbedrede visjonen og prosessen kan vi nærme oss ledelsen og sette et klart bilde av resultatene, for eksempel hvor jevn prosessen var, hvordan risikoen for svikt ble redusert, hvordan oppgaven ble fullført før tidslinjen, etc.
Nå kan vi tydelig visualisere hvordan hele prosessen ble optimalisert på teknisk og kulturelt grunnlag ved å ha tilbakeblikk etter hver iterasjon.
Edureka har spesialkuratert som hjelper deg med å mestre konsepter rundt Puppet, Jenkins, Ansible, SaltStack, Chef blant andre.
Har du et spørsmål til oss? Nevn dem i kommentarfeltet, så kommer vi tilbake til deg.
Relaterte innlegg: