Kultura se često zanemaruje i pogrešno shvaća, no ona je ključni faktor odgovoran za uspješnost tvrtke. Ako ne upravljamo svojom kulturom, na kraju ćemo raditi pogrešne prakse što će u konačnici utjecati na naše poslovne ciljeve.
Razumijevanje trenutne kulture organizacije
Kultura nam govori o vrijednostima i normama unutar grupe ili tvrtke. Identificira ono što je važno, kao i način na koji ljudi pristupaju i rade jedni s drugima.
KULTURA = 'Kako se stvari mogu pametno učiniti za uspjeh'
Uzmimo primjer tima za korisničku podršku. Kultura tog tima trebala bi biti takva da na kraju postignu 97-98% zadovoljstva kupaca.
Imajući na umu oduševljenje kupaca, prije svega moraju biti pristojni, čak i u teškim situacijama moraju biti dobri slušatelji kako ne bi došlo do zabune koja im treba da daju prioritet u radu prema zahtjevima.
Zastanimo na trenutak i postavimo sebi nekoliko pitanja:
- Kakva je kultura moje tvrtke sada?
- Koliko je dobro ta kultura usklađena s mojim poslovnim ciljevima ili KRA-ima?
- Koje probleme mogu očekivati zbog neusklađenosti?
Za svaku organizaciju, 4Cs igra vitalnu ulogu
Pogledajmo sada kulturu organizacije koja se bavi razvojem softvera. Mnogo je timova uključenih u izgradnju i održavanje jedne softverske jedinice. Svi ti timovi imaju zasebne ciljeve i odvojenu kulturu.
Ovaj postupak započinje nakon što klijent potvrdi zahtjeve.
Programeri se pridržavaju smjernica za kodiranje koje definira njihova organizacija, a za generiranje koda koriste se programski alati poput kompajlera, interpretatora, programa za uklanjanje pogrešaka itd. Za kodiranje se koriste različiti programski jezici visoke razine poput C, C ++, Pascal, Java i PHP.
Kompletni paket dijele u male mape, a zatim prema tome razvijaju male kodove.
Faza 1 : Te male jedinice kodova udružuju se tako da tvore veliku jedinicu. Tijekom integriranja manjih čipova, mora se provesti testiranje na razini projekta poznato kao integracijsko testiranje.
Faza 2 : Nakon uspješne integracije implementira se u lažni sustav. Ovaj lažni sustav ima sličnu konfiguraciju kao onaj klijentskog stroja ili stroja na kojem se ovaj projekt mora konačno implementirati.
Faza 3 : Napokon, nakon testiranja svih značajki u lažnom sustavu, projekt se postavlja na proizvodni poslužitelj ili klijentski stroj.
Iako se čini da je ovaj postupak vrlo gladak i lagan u riječima, u tehničkom je pogledu vrlo teško postići.
Pogledajmo s kojim bismo se problemima mogli suočiti:
vrste transformacija u informatici
Faza 1 :
Klijent je uvijek u potrazi za promjenama kako bi poboljšao kvalitetu proizvoda. Većinu vremena kada je izvršena prva iteracija, klijent će predložiti nekoliko promjena. Kad programeri prime promjene, počinju ih ugrađivati što utječe na integraciju koja dovodi do pokvarenih gradnji.
Faza 2:
Većinu vremena testeri ili drugi operateri neće biti svjesni novih promjena koje treba uvesti. Čim dobiju kod od programera, počinju ih testirati. Iako na pozadini, programeri još uvijek unose promjene.
Kako ne dobivaju dovoljno vremena za provođenje novih promjena, na kraju razvijaju neučinkovite kodove s kojima se suočavaju s drugim problemima s mrežom i bazama podataka, što opet odgađa njihovo vrijeme isporuke.
Kad napokon dostave kodove operativnom timu, ostaje im vrlo malo vremena za stvaranje i implementaciju novih testnih slučajeva. Tako preskaču mnoge ispitne slučajeve za koje su kasnije shvatili da su im bili od visokog prioriteta.
Faza 3:
Iako se čini da je verzija gotovo spremna za proizvodnju, ali rezultati su potpuno neočekivani. Izgradnja ne uspijeva i javljaju se brojne bugove.
Tada za svaku pogrešku koja se dogodila moraju pratiti zašto se dogodila, gdje se dogodila, koje promjene treba poduzeti da bi se prevladale, hoće li doći do promjena u drugim kodovima kako bi bila kompatibilna s prethodnima. Konačno, za sve ove bugove treba generirati izvještaj o bugovima.
Kvar je zbog sistemskih pogrešaka zbog neznanja programera baze podataka u učinkovitosti koda, neznanja testera u broju test slučajeva itd.
Kako klijent uvijek drži rok, zaposlenici koji su uključeni u njihovo postizanje koncentriraju se samo na konačno izdanje, čak i ako moraju ugroziti ukupnu kvalitetu.
Iako se čini da je ovo problem u koordinaciji posla, ovo je zapravo neuspjeh usvojene kulture.
To se događa zbog velike ovisnosti o ručnim procesima. Trčanje tamo-amo u istom timu zbog nedostatka znanja iz različitih područja, nedostatka pristupa ili nedostatka interesa povećava naš vlastiti teret i bol.
Krajnje je vrijeme da trebamo biti svestrani. Možda će biti teško biti gospodar svih procesa koji su uključeni u sustav, ali možemo biti dizalica svih, svladavajući jedan među njima. Tada samo mi možemo automatizirati svoj sustav ili ga učiniti dovoljno inteligentnim da se oporavi umjesto vraćanja.
Sad, možda razmišljate zašto?
To je zato što, onaj koga svladate jako ovisi o drugima. Da bismo znali o točki ovisnosti, moramo razumjeti cijeli sustav.
Pa razmislimo o procesu promjene kulture. Imate li prije toga odgovor na pitanja u nastavku?
- Gdje propada vaša trenutna kultura?
- Zašto želite promijeniti postupak?
- Jeste li jasno identificirali sve potrebne promjene?
- Jeste li dobili povratne informacije i kupnju od svih pogođenih dionika?
- Jeste li revalidirali procesnu disciplinu, podatke i mjerni sustav za promjenu?
Dakle, sada kada imamo odgovor na sve, razmišljamo o revoluciji u našem sustavu. Kako će se dogoditi ova revolucija? To se može postići samo kad ubijemo ono što smo sada. Puno se vremena gubi na migraciju koda među timovima. Moramo dovesti proces u kojem možemo kontinuirano integrirati i kontinuirano implementirati.
Ovaj postupak kontinuirane integracije i implementacije čini ga agilnijim. Donošenje ove okretnosti smatra se kulturom DevOps.
DevOps je praksa operativnih i razvojnih inženjera koji zajedno sudjeluju u cijelom životnom ciklusu, od dizajna preko razvojnog procesa do proizvodne podrške.
razlika između qtp i selena
Nije lako promijeniti radni sustav tijekom vremena. Uspješna tranzicija je obnova sustava, a ne obnova.
Sada da vidimo kako to možemo postići. Postoje dva načina pristupa.
1) Odozgo prema dolje
što je tečaj znanosti o podacima
2) Dno prema gore
Zaronivši dublje u ove tehnike, shvatit ćemo koja je najprikladnija za našu organizaciju.
U pristupu od vrha prema dolje možemo otići do višeg menadžmenta i tražiti od njih promjene u svim timovima. Ako je tada uprava uvjerena, možemo početi raditi na tome.
Ali vjerojatnost da ćete dobiti odgovor kao 'NE' prilično je velika. To je zato što promjena sustava može dovesti organizaciju do nestabilnosti.
Moraju istražiti strukturu organizacije, prihode, razinu interesa klijenta itd. Ali najvažniji čimbenik koji ih vuče od iskoraka iz starog sustava je da ne mogu vidjeti velika slika onoga što se može postići i koliko se glatko može postići novijim.
U ovom slučaju možemo potražiti drugi pristup da bismo dobili ovu veliku sliku.
Pristup odozdo prema gore poziva na volontiranje. Ovdje moramo uzeti mali tim i mali zadatak i izvršiti ga u DevOps modelu.
Gledajući tehničku stranu ovog modela, imamo razne skupove sofisticiranih alata koji čine rad učinkovitijim i bržim. Ali, sami alati nisu dovoljno sposobni za stvaranje suradničkog okruženja koje se naziva DevOps.
Stvaranje takvog okruženja zahtijeva da razmišljate izvan okvira, na pr. procjenu i preusmjeravanje mišljenja ljudi o svojim timovima, poslu i kupcima.
Sastavljanje novog skupa alata jednostavnije je od promjene organizacijske kulture. Promoviranjem glavnih društvenih programera, omogućavanjem integriranja neučinkovitog koda, postavljanjem kodova koji nisu pravilno testirani, stavljanjem krivnje jedni drugima na glavu, smatrajući operativni tim glupim, nisu najbolja praksa koju slijedimo kako bi omogućili poslovanje i stvoriti vrijednost za naše kupce.
Nisu alati, već ljudi koji ih koriste, taj postupak čine složenim. Reći na apstraktnoj razini, a ne prikupljati ideje i ponašanja, biti otvoren za njih vodi nas na svijetli put.
Počnimo s timom od 6 članova i pričom od 3 boda. Prvo moramo razbiti tim koji nazivamo programerima, operaterima, testerima itd. Smatramo da su svi jedno, recimo 'DevOps'. Kad primimo zahtjeve, trebamo analizirati zone rizika. Imajući na umu dublje dijelove mora i hellip .. Počinjemo ploviti.
Sada morate razmišljati 'koji je x faktor ove kontinuirane integracije i kontinuiranog postavljanja koji smanjuje vjerojatnost neuspjeha'.
S poboljšanom vizijom i postupkom možemo pristupiti menadžmentu dajući jasnu sliku rezultata poput toga koliko je proces bio gladak, kako je smanjen rizik od neuspjeha, kako je zadatak dovršen prije vremenske trake itd.
Sada možemo jasno predočiti kako je čitav postupak optimiziran na tehničkom i kulturnom tlu retrospektivom nakon svake iteracije.
Edureka je posebno kustos koji vam pomaže savladati koncepte oko Lutke, Jenkinsa, Ansiblea, SaltStacka, Chefa, između ostalih.
Imate pitanje za nas? Spomenite ih u odjeljku za komentare i javit ćemo vam se.
Vezane objave: