Kultura jest często ignorowana i źle rozumiana, ale jest ona kluczowym czynnikiem odpowiedzialnym za wyniki firmy. Jeśli nie będziemy zarządzać naszą kulturą, w końcu będziemy postępować niewłaściwie, co ostatecznie wpłynie na nasze cele biznesowe.
Zrozumienie obecnej kultury organizacji
Kultura mówi nam o wartościach i normach w grupie lub firmie. Określa, co jest ważne, a także jak ludzie podchodzą i pracują ze sobą.
CULTURE = „Jak można mądrze osiągnąć sukces”
Weźmy przykład zespołu obsługi klienta. Kultura tego zespołu powinna być taka, aby ostatecznie osiągał 97-98% satysfakcji klienta.
Mając na uwadze zadowolenie klienta, przede wszystkim muszą być uprzejmi, nawet w trudnych sytuacjach muszą być dobrymi słuchaczami, aby uniknąć nieporozumień, muszą ustalić priorytety pracy zgodnie z wymaganiami.
Zatrzymajmy się na chwilę i zadajmy sobie kilka pytań:
- Jaka jest teraz kultura mojej firmy?
- Jak dobrze ta kultura jest zgodna z moimi celami biznesowymi lub KRA?
- Jakich problemów mogę się spodziewać z powodu niewspółosiowości?
W każdej organizacji 4C odgrywa kluczową rolę
Przyjrzyjmy się teraz kulturze organizacji tworzącej oprogramowanie. Istnieje wiele zespołów zaangażowanych w tworzenie i utrzymywanie pojedynczej jednostki oprogramowania. Wszystkie te zespoły mają odrębne cele i odrębną kulturę.
Proces ten rozpoczyna się po potwierdzeniu wymagań przez klienta.
Programiści postępują zgodnie z wytycznymi dotyczącymi kodowania określonymi przez ich organizację, a narzędzia programistyczne, takie jak kompilatory, interpretery, debuggery itp., Są używane do generowania kodu. Do kodowania używane są różne języki programowania wysokiego poziomu, takie jak C, C ++, Pascal, Java i PHP.
Dzielą cały pakiet na małe foldery, a następnie odpowiednio opracowują małe kody.
Scena 1 : Te małe jednostki kodów są następnie składane w celu utworzenia dużej jednostki. Podczas integracji mniejszych układów należy przeprowadzić testy na poziomie projektu, zwane testami integracyjnymi.
Etap 2 : Po pomyślnej integracji jest wdrażany w systemie fikcyjnym. Ten fałszywy system ma podobną konfigurację jak komputer klienta lub komputer, na którym projekt ma zostać ostatecznie wdrożony.
Etap 3 : Wreszcie, po przetestowaniu wszystkich funkcji w fałszywym systemie, projekt jest wdrażany na serwerze produkcyjnym lub na komputerze klienckim.
Chociaż ten proces wydaje się być bardzo płynny i łatwy w słowach, pod względem technicznym jest bardzo trudny do osiągnięcia.
Zobaczmy, jakie problemy możemy napotkać:
Scena 1 :
różnica między javascript i jquery
Klient zawsze poszukuje zmian w celu poprawy jakości produktu. W większości przypadków po wykonaniu pierwszej iteracji klient zasugeruje kilka zmian. Gdy programiści otrzymują zmiany, zaczynają je wprowadzać, co wpływa na integrację, prowadząc do zepsutych kompilacji.
Etap 2:
W większości przypadków testerzy lub inni operatorzy nie będą świadomi nowych zmian, które mają zostać wprowadzone. Gdy tylko otrzymają kod od programistów, zaczynają go testować. Na zapleczu deweloperzy wciąż wprowadzają zmiany.
Ponieważ nie mają wystarczająco dużo czasu na wdrożenie nowych zmian, w końcu opracowują nieefektywne kody, napotykają inne problemy z siecią i bazami danych, które ponownie opóźniają ich dostarczenie.
Kiedy w końcu dostarczą kody do zespołu operacyjnego, pozostaje im bardzo minimalny czas na tworzenie i wdrażanie nowych przypadków testowych. Dlatego pomijają wiele przypadków testowych, z których później zdają sobie sprawę, że miały one wysoki priorytet.
Etap 3:
Choć praktycznie kompilacja wydaje się być gotowa do produkcji, ale wyniki są całkowicie nieoczekiwane. Kompilacja kończy się niepowodzeniem i pojawia się szereg błędów.
Następnie, przy każdym wystąpieniu błędu, muszą śledzić, dlaczego tak się stało, gdzie wystąpił, jakie zmiany należy wprowadzić, aby go usunąć, czy nastąpi zmiana w kodach innych osób, aby były zgodne z poprzednimi. Wreszcie dla wszystkich tych błędów należy wygenerować raport o błędzie.
Niepowodzenie jest spowodowane błędami systemowymi wynikającymi z niewiedzy programisty bazy danych w zakresie wydajności kodu, ignorancji testera w zakresie liczby przypadków testowych itp.
Ponieważ klient zawsze dotrzymuje terminów, pracownicy zaangażowani w ich osiągnięcie koncentrują się tylko na ostatecznym wydaniu, nawet jeśli muszą zagrozić ogólnej jakości.
Choć wydaje się, że jest to problem z koordynacją pracy, w rzeczywistości jest to porażka przyjętej kultury.
pytania do wywiadu dotyczącego usługi Salesforce w chmurze
Dzieje się tak z powodu dużej zależności od procesów ręcznych. Bieganie tam iz powrotem w tym samym zespole z powodu braku znajomości różnych dziedzin, brak dostępu lub brak zainteresowania, zwiększa nasze własne obciążenie i ból.
Najwyższy czas, abyśmy byli wszechstronni. Być może trudno jest opanować wszystkie procesy występujące w systemie, ale możemy być mistrzem wszystkich, opanowując jeden z nich. Tylko wtedy możemy zautomatyzować nasz system lub uczynić go wystarczająco inteligentnym, aby odzyskać, a nie wycofywać.
Teraz możesz się zastanawiać, dlaczego?
Dzieje się tak dlatego, że osoba, którą opanowujesz, jest wysoce zależna od innych. Aby wiedzieć o punkcie zależności, musimy zrozumieć cały system.
Pomyślmy więc o procesie zmiany kultury. Czy przedtem masz odpowiedź na poniższe pytania?
- Gdzie twoja obecna kultura zawodzi?
- Dlaczego chcesz zmienić ten proces?
- Czy jasno określiłeś wszystkie wymagane zmiany?
- Czy otrzymałeś opinie i poparcie od wszystkich zainteresowanych stron?
- Czy zrewidowałeś dyscyplinę procesu, dane i system pomiarowy dla zmiany?
Więc teraz, kiedy mamy odpowiedź dla wszystkich, myślimy o rewolucji w naszym systemie. Jak będzie miała miejsce ta rewolucja? Można to osiągnąć tylko wtedy, gdy zabijemy to, czym jesteśmy teraz. Migracja kodu pomiędzy zespołami marnuje dużo czasu. Musimy wprowadzić proces, w którym możemy dokonywać ciągłej integracji i ciągłego wdrażania.
Ten proces ciągłej integracji i wdrażania sprawia, że jest on bardziej elastyczny. Zapewnienie tej elastyczności jest uważane za kulturę DevOps.
DevOps to praktyka, w której inżynierowie operacyjni i programistyczni uczestniczą razem w całym cyklu życia usługi, od projektowania, przez proces rozwoju, po wsparcie produkcyjne.
Zmiana systemu pracy z czasem nie jest łatwa. Udane przejście polega na odnowieniu systemu, a nie na jego odbudowie.
Zobaczmy teraz, jak możemy to osiągnąć. Można podejść na dwa sposoby.
1) Od góry do dołu
2) Oddolne
Zagłębiając się w te techniki, zdamy sobie sprawę, która z nich jest najlepsza dla naszej organizacji.
W podejściu odgórnym możemy udać się do wyższego kierownictwa i poprosić ich o wprowadzenie zmian we wszystkich zespołach. Jeśli kierownictwo jest przekonane, możemy zacząć nad tym pracować.
Jednak prawdopodobieństwo uzyskania odpowiedzi „NIE” jest dość wysokie. Dzieje się tak, ponieważ zmiana systemu może doprowadzić organizację do niestabilności.
Muszą przyjrzeć się strukturze organizacji, przychodom, poziomowi zainteresowania klienta itp. Ale najważniejszym czynnikiem, który odciąga ich od wychodzenia ze starego systemu jest to, że nie widzą duży obraz tego, co można osiągnąć i jak płynnie można to osiągnąć za pomocą nowszego.
W takim przypadku możemy poszukać drugiego podejścia, aby uzyskać ten duży obraz.
Podejście oddolne wymaga ochotników. Tutaj musimy wziąć mały zespół i małe zadanie i wykonać je w modelu DevOps.
Patrząc od strony technicznej tego modelu mamy do dyspozycji różnorodny zestaw wyrafinowanych narzędzi, które sprawiają, że praca jest wydajniejsza i szybsza. Jednak same narzędzia nie są w stanie stworzyć środowiska współpracy zwanego DevOps.
Stworzenie takiego środowiska wymaga nieszablonowego myślenia, np. ocena i zmiana sposobu myślenia ludzi o swoich zespołach, firmie i klientach.
Utworzenie nowego zestawu narzędzi jest prostsze niż zmiana kultury organizacyjnej. Promowanie antyspołecznych mistrzów, pozwalanie na integrację nieefektywnego kodu, wdrażanie kodów, które nie zostały odpowiednio przetestowane, obwinianie się nawzajem, uważanie zespołu operacyjnego za głupiego, nie są najlepszymi praktykami, które stosujemy, aby umożliwić biznesowi i tworzyć wartość dla naszych klientów.
To nie narzędzia, ale ludzie, którzy ich używają, komplikują proces. Mówienie na abstrakcyjnym poziomie zamiast zbierania pomysłów i zachowań, otwarcie na nie prowadzi nas na jasną ścieżkę.
Zacznijmy od 6-osobowego zespołu i 3-punktowej historii. Po pierwsze, musimy rozbić zespół, do którego dzwonimy jako programiści, operatorzy, testerzy, itd. Uważamy ich za jednego, powiedzmy „DevOps”. Kiedy otrzymujemy wymagania, musimy przeanalizować strefy ryzyka. Mając na uwadze głębsze odcinki morza i hellipu ... Rozpoczynamy żeglowanie.
Teraz musisz pomyśleć „jaki jest współczynnik x tej ciągłej integracji i ciągłego wdrażania, który zmniejsza prawdopodobieństwo niepowodzenia”.
Dzięki ulepszonej wizji i procesowi możemy podejść do kierownictwa, przedstawiając jasny obraz rezultatów, takich jak płynność procesu, zmniejszenie ryzyka niepowodzenia, wykonanie zadania przed terminem itp.
Teraz możemy wyraźnie wyobrazić sobie, jak cały proces został zoptymalizowany pod względem technicznym i kulturowym, dzięki retrospekcji po każdej iteracji.
Edureka jest specjalnie kuratorem który pomaga opanować koncepcje dotyczące między innymi Puppet, Jenkins, Ansible, SaltStack, Chef.
Masz do nas pytanie? Wspomnij o nich w sekcji komentarzy, a my skontaktujemy się z Tobą.
Powiązane posty:
java głębokie kopiowanie vs płytkie kopiowanie