Co robić jako deweloper, gdy od lat w ich zespole brakowało innowacji produktowych, nie stosował metodologii projektu i utrzymywał złe praktyki deweloperów oprogramowania? [Zamknięte]

14

Jestem zainteresowany wiedzą, jak radzić sobie z obecnym procesem tworzenia oprogramowania, który nie był zmieniany od lat i ostatecznie doprowadzi do awarii produktu i zespołu. Tak, prawdopodobnie najłatwiejszym sposobem rozwiązania tego problemu jest zmiana pracy, ale w tej gospodarce łatwiej powiedzieć niż zrobić. Jeśli jednak masz konkretne przykłady i widziałeś lub byłeś wielokrotnie w tej samej sytuacji i uważasz, że najlepszym rozwiązaniem tych problemów jest odejście z firmy, to proszę o wsparcie. Chodzi o to, że to pytanie naprawdę ma odpowiedź, zwłaszcza jeśli wielu ekspertów w tej dziedzinie ostatecznie wskazuje, że najlepszą drogą jest: trasa A.

Wiem, że mnóstwo programistów było lub jest w podobnych sytuacjach. Jest to jeden z głównych powodów, dla których firmy przechodzą z pozycji nr 1 na rynku do bycia ostatnimi, a nawet wycofania się z rynku. Mamy nadzieję, że odpowiedzi w tym poście pomogą innym programistom napotkać podobne przeszkody. W małym lub dużym zespole programistów zwykle dzieje się tak:

  • Wydaje się, że niektórzy programiści nie przejmują się tym i decydują się pójść z prądem i wolą pozostawić kod z dużą ilością zapachu kodu, jaki jest, i proces programowania taki, jaki jest,
  • Inni zmęczyli się brakiem zmian, zrezygnowali i przenieśli się do innej firmy,
  • Inni wydają się bać rozmawiać i wolą milczeć,
  • Czasami bardzo niewielu programistów lub tylko jeden próbuje zabrać głos za ulepszeniem produktu i mówi zespołowi, jak ważne jest przestrzeganie najlepszych praktyk kodowania i korzyści płynące z tego dla klientów, użytkowników i zespołu. Tego rodzaju programiści zwykle decydują się pozostać w zespole z takich powodów, jak firma oferuje korzyści, które oferuje bardzo niewiele firm programistycznych, lub produkt ma duży potencjał itp.

Produkt w naszym zespole to tylko ułamek tego, z czego firma czerpie dochód, ponieważ ma parasol produktów (ta firma nie jest firmą programistyczną / sprzętową; dlatego nie ma ciągłych sporów patentowych, przynajmniej na razie, co tworzy miejsce pracy niestabilność). Do tej pory nauczyłem się w ciągu tych lat z doświadczeń innych programistów i z mojego doświadczenia, że ​​aby naprawdę poznać zespół programistów, potrzeba czasu, nie dni ani tygodni, ale kilka miesięcy. Podczas procesu rozmowy, jeśli zespół chce cię zatrudnić lub potrzebuje; sprawiają, że wszystko brzmi świetnie i mogą powiedzieć ci, co chcesz usłyszeć. Rzeczywistość jest jednak inna, gdy zaczniesz pracować w tym zespole i zaczniesz kopać kod i przejść do pełnego procesu SDLC. Wtedy, jako programista, zaczynasz widzieć rzeczywistość pracy, w którą się zaangażowałeś. Ta rzeczywistość utrudnia przejście z jednej firmy do drugiej, ponieważ trudno jest ustalić, czy firma, do której się przeprowadzasz, będzie lepsza czy gorsza. Tak, możesz przeczytać recenzje Glassdoor itp., Ale ile z tych recenzji online jest prawdziwych, a nie od HR?

Jaki byłby najlepszy sposób rozwiązania problemów opisanych poniżej, biorąc pod uwagę, że menedżer od początku zawsze opierał się zmianom, a poprzedni programiści robili to samo od lat?

  • Brak produktu Innowacja od lat: Produkt ma duży potencjał i przynosi firmie dobre dochody, ale wygląda na to, że powstał 20 lat temu. Niektórzy użytkownicy skarżyli się, że produkt nie jest przyjazny ani intuicyjny, a inni wspomnieli, że są przyzwyczajeni do aplikacji takich jak Gmail i denerwują się podczas korzystania z produktu z powodu braku podobnych funkcji. Głównym problemem jest to, że kiedy próbujesz jako programista wprowadzić zmiany w produkcie i zaczniesz przenosić główne elementy produktu w odległości zaledwie kilku pikseli (aby uczynić go bardziej przyjaznym dla użytkownika lub intuicyjnym), panikuje i mówi ci odłożyć to tam, gdzie było. Jeśli spróbujesz dodać funkcję, która zwiększy wydajność użytkowników, menedżer poprosi cię o jej usunięcie, ponieważ „użytkownicy są przyzwyczajeni do wykonywania tego procesu tak, jak to jest itp.” Myślę, że rozumiesz opór przed zmianami, ulepszeniami i innowacjami (menedżer nie jest otwarty na zmiany, nawet jeśli jako programista dostarczasz silnych argumentów za korzyściami). Firma ma kilku konkurentów w tej dziedzinie (produkty kilku z nich są znacznie bardziej konkurencyjne), ale w jakiś sposób firma utrzymała obecnych klientów od lat.

  • Brak koordynacji zarządzania projektami: w rezultacie niektóre projekty są dostarczane z opóźnieniem, błędy i niektórzy klienci narzekają (klienci zgłaszają również błędy) lub budżet jest wykorzystywany zbyt szybko przed dostarczeniem projektu itp. Dostarczam je Kilka wskazówek dotyczących koordynacji projektów i pomysłów jest obecnie regularnie wykorzystywanych do śledzenia postępów projektów i zadań do wykonania.

  • Złe praktyki programistyczne: Zapach kodu jest widoczny w większości, jeśli nie we wszystkich plikach, brak dokumentacji, redundancji kodu, warstwy frontonu i zaplecza w tym samym pliku, nieaktualne narzędzia programistyczne, brak prawdziwego środowiska testowego ani narzędzi testowych (wystarczy skopiować i wkleić pliki ze środowiska deweloperskiego do produkcji, a następnie ręcznie przetestuj, czy wszystko wygląda dobrze i wypuść). Większość narzędzi programistycznych, których używam do programowania i testowania, jest nieznana zespołowi, ponieważ zespół używa tylko 2 IDE do programowania kodu i kontroli źródła jest dostępny tylko dla środowiska programistycznego. Inni programiści próbowali wykorzystać najnowsze frameworki, aby poprawić bieżące problemy, ale menedżerowi nie podoba się to z powodu „co jeśli odejdziesz, to kto będzie utrzymywał ten kod ?, zostawmy to tak, jak jest” Niektórzy z tych programistów już odszedł i przeniósł się do innej firmy.

Podsumowując, jestem pewien, że podobne sytuacje zdarzają się wielu programistom w innych firmach, ale z powodu różnych okoliczności deweloper może woli pozostać w zespole niż udać się do innej firmy z powodów takich jak (wygoda pracy, elastyczność pracy, korzyści dla firmy lub tylko dlatego, że nie pojawiła się lepsza okazja). Nie znam doskonałej firmy, o której wiem, ale jak zachowałbyś się jako programista i podchodziłbyś do tych wszystkich kwestii, aby utrzymać pozytywne nastawienie i ostatecznie promować zmiany w celu ulepszenia produktu i ulepszenia procesu tworzenia oprogramowania (czy masz wiele lata doświadczenia programistycznego czy tylko kilka)? Wiem, że ten post jest długi, ale wolałem podać dodatkowe szczegóły, aby zwiększyć szanse na uzyskanie bardziej przydatnych informacji zwrotnych.

Bardzo dziękuję za wszystkie opinie i czas

kami
źródło
Zmienić pracę? ...
Robert Harvey
1
Dla przypomnienia, wiele recenzji Glassdoor jest prawdziwych z mojego doświadczenia.
Telastyn
1
Czy Twój menedżer jest kierownikiem ds. Rozwoju, czy kierownikiem produktu, tj. Tym, który decyduje o priorytecie elementów do opracowania na podstawie wartości biznesowej, którą reprezentują?
Marjan Venema,
4
Zdajesz sobie sprawę, że duże kule błota faktycznie działają , prawda?
Denis de Bernardy
4
Istotne są przynajmniej części „ Robiąc rzeczy, gdy jesteś tylko żartem” Joela Spolsky'ego .
AakashM

Odpowiedzi:

18

Cytat Martina Fowlera jest istotny: „Możesz zmienić swoją organizację lub zmienić swoją organizację”. Biorąc pod uwagę, że najwyraźniej zdecydowałeś się zmienić organizację (uczynić ją lepszą) zamiast zmienić organizację (pracować dla innej organizacji), oto kilka sugestii.

Po pierwsze, wiele z twoich działań zależy od szczegółów na temat struktur władzy i polityki w pracy. Czy jest jeden lub kilku menedżerów ds. Rozwoju oprogramowania? Jeśli jest ich kilka, czy są tacy, którzy nie są niechętni do zmiany? Ilu jest programistów? Czy programiści są zainteresowani zmianą? Jeśli tak, to należy wprowadzić pewne zmiany, nawet bez zgody kierownictwa. (Jak sugeruje Fowler w Refaktoryzacji , być może nawet nie będziesz musiał powiedzieć zarządowi. Prawdopodobnie jesteś zatrudniony do tworzenia oprogramowania najlepiej jak potrafisz, więc jeśli istnieje lepszy sposób, po prostu to zrób).

Po drugie, pamiętaj, że kierownictwo może mieć dobre powody tego, co robi. Jesteś programistą; Twoim zadaniem jest opracowanie dobrego oprogramowania i poznanie dobrych technik w tym zakresie. Zadaniem kierownictwa jest zrozumienie większych problemów związanych z obrazem i rozważań biznesowych, które mogą wykraczać poza twoje możliwości. Nawet jeśli masz rację i nie mają racji co do tego, jakie są względy biznesowe (obawy dotyczące braku innowacji, opóźnień w dostawie, skarg klientów itp.), Zrozumienie, skąd pochodzi zarządzanie, pomoże ci komunikować się na ich warunkach, złagodzić ich obawy i tak dalej.

Po trzecie (i powiązane), upewnij się, że znasz język biznesu. Firma (słusznie) nie jest bezpośrednio zainteresowana dobrymi praktykami rozwoju oprogramowania; firma zajmuje się zaspokajaniem potrzeb klientów i osiąganiem zysków. (I wiele firm w oczywisty sposób zrobi minimalne potrzeby, aby osiągnąć zysk.) Będziesz bardziej skuteczny w promowaniu zmian, jeśli potrafisz wyjaśnić, w jaki sposób złe praktyki tworzenia oprogramowania i brak innowacji zaszkodzą zyskowi firmy lub długoterminowo zdrowie.

Po czwarte, zmiana kultury firmowej ze stanowiska szeregowego pracownika jest niezwykle trudna. James Shore (zwinny konsultant i autor) napisał dziennik zmian, w którym opisał swoje wysiłki. Zdecydowanie polecam przeczytanie całości. Kilka istotnych punktów:

  • Nie próbuj zmieniać wszystkiego na raz. Znajdź największe punkty bólu i zacznij od tego. Zaangażuj wszystkich, pomagając im zobaczyć, w jaki sposób zmiany rozwiązują te problemy.
  • Poznaj perspektywy innych. Shore mówi o tym, jak kierownik projektu oparł się zmianom, które naciskał z perspektywy rozwoju oprogramowania, ponieważ on (Shore) nie zastanawiał się, w jaki sposób zmiany wpłyną na kierownika projektu.
  • W końcu, trzeba trochę wsparcia ze strony wyżej, nawet jeśli skłania większość yourself zmian. Shore mówi o swoim mistrzu („ktoś, z kim pracuję, który ma większą siłę ode mnie i myśli ogólnie tak samo jak ja”).
Josh Kelley
źródło
4
praktyczne porady, zbyt wiele razy deweloperzy myślą tylko w oparciu o bazę kodów, a nie w kategoriach biznesowych, i tęsknią za ogromnym obrazem, który składa się na to, co robimy i dlaczego.
gbjbaanb
Shore mówi o swoim bohaterze („ktoś, z kim pracuję, który ma większą siłę ode mnie i myśli ogólnie tak samo jak ja” - do tego muszę dodać „ale nie próbuje niczego zmienić”. Nie oczekuj za dużo
Mawg mówi, że przywróć Monikę
10

Oczywistą krótką odpowiedzią jest odejście z firmy. Inni już odeszli, a twój menedżer stanowi aktywną przeszkodę w rozwoju. Jeśli pozostaniesz w tej pozycji, powoli się rozpadniesz (zarówno pod względem morale, jak i umiejętności). Znalezienie nowej pracy nie zawsze jest łatwe, ale w tym przypadku jest konieczne.

Na wszelki wypadek, gdy zdecydowałeś się nie opuszczać firmy (pierwsza linijka twojego pytania to rozdała):

Czy twój menedżer ma szefa? Jeśli tak, w jaki sposób ten szef postrzega produkt? Czy potrafisz (czy w ogóle mogę to powiedzieć?) Przejść nad głową swojego menedżera i zbliżyć się do jego szefa? Nie dokuczaj mu szczegółami technicznymi, po prostu wyrażaj zainteresowanie i entuzjazm w rozwoju w firmie. Przedstaw namacalne pomysły na ulepszenia, które miałyby wymierny wpływ na wynik końcowy. Możesz awansować spod przeszkody.

Ostrzegamy jednak - podczas gdy niektóre skrzypiące koła są smarowane, inne wymieniane. Sprawisz, że twój menedżer bardzo cię nie polubi. On będzie usłyszeć o tym, a on będzie powiedzieć niemiłych rzeczy o was do swojego szefa. Stąpaj ostrożnie, ale pamiętaj - bez ryzyka, bez nagrody.

Najgorsze, co może się zdarzyć, to to, że będziesz szukał nowej pracy, którą i tak powinieneś wykonywać.

Dan Pichelman
źródło
2
Przepraszam, musiałem przegłosować, ponieważ OP mówi konkretnie, że nie szuka porady w stylu „Poszukaj nowej pracy”.
KChaloux
4
@KChaloux - Dziękujemy za opinię. Większość mojej odpowiedzi nie brzmi „szukaj nowej pracy”, ale czułem, że pominięcie tego fragmentu byłoby niekorzystne i skutkowało niepełną odpowiedzią.
Dan Pichelman,
9

Wygląda na to, że nadszedł czas, aby dowiedzieć się o krowach gotówkowych. Idź tu i tutaj . I spójrz na Matrycę wzrostu . GSM zapewnia dodatkowe informacje na temat tego, dlaczego krowa gotówkowa jest w dobrym stanie.

Investopedia (drugi link) ma prawdopodobnie najlepszą ofertę w tym przypadku.

  1. Krowa gotówkowa wymaga niewielkiego kapitału inwestycyjnego i nieprzerwanie zapewnia dodatnie przepływy pieniężne, które można przypisać do innych działów korporacji. Te podmioty generujące środki pieniężne mogą również wykorzystywać swoje pieniądze do odkupu akcji na rynku lub wypłacać dywidendy akcjonariuszom.

Jak zauważyłeś, istnieje kilka zalet bycia w projekcie krowy gotówkowej.

  • Jest stabilny
  • Gwarantowany jest niewielki stopień nowego rozwoju
  • W rozwiązywaniu problemów zawsze są prace naprawcze.

I, jak zauważyłeś, są pewne wady tych projektów.

  • Jest stabilny, a podstawa kodu niewiele się zmienia
  • Nowe technologie są na ogół ignorowane (zbyt drogie, aby je wykorzystać)
  • I rzeczy stają się ... nieświeże.

Kiedyś pracowałem nad projektem, w którym miałem wiele podobnych skarg jak to, co podniosłaś. Wyraźnie pamiętam, jak wtedy podzieliłem się z szefem swoimi obawami dotyczącymi bazy kodu. Jego wgląd nie był szczególnie pouczający, więc nie podzielę się nim. Ale wystawiłem projekt i prawdę mówiąc, był to jeden z lepszych projektów, jakie widziałem. Nie, to nie było krzykliwe. Tak, nie dotrzymaliśmy terminów. Tak, stamtąd zebrałem kilka marszów śmierci. Nie, technologia kodowania nie była aż tak innowacyjna, ale stworzyliśmy niesamowite rozwiązania.

Problemem byłam ja. Nie miałem wystarczającej perspektywy, aby zrozumieć, czego tak naprawdę wymaga baza kodu, aby przetrwać. Nie miałem doświadczenia, aby zobaczyć, gdzie naprawdę nastąpiła innowacja. Nie rozumiałem podstaw rynkowych, które decydowały o tym, jaki był odpowiedni poziom finansowania tego projektu krowy gotówkowej.

Zachęcam do postrzegania tego jako okazji do nauki, aby lepiej zrozumieć, jak działa biznes i jak poprawić swoje umiejętności w zakresie dostosowywania produktu do potrzeb firmy. Chociaż praca może nie być krzykliwa, potencjał uczenia się jest wysoki, a umiejętności te zapewnią ci dobrą pozycję w dalszej karierze. Większość rozwoju na poziomie korporacyjnym opiera się na wszystkich ograniczeniach, które właśnie wymieniłeś. Kod śmierdzi; wszystko zostało spreparowane, by zawierać terminy, które już minęły; wielu programistów jest odpornych na zmiany.

W pewnym momencie nadal będziesz przechodzić od projektu. Lekcje, które możesz zabrać ze sobą, mogą być prawdziwymi lekcjami tworzenia kariery.


źródło
2
+1, widziałem firmy działające w tym trybie od ponad dekady. Gdy osiągną pewną bezwładność, będą działać przez długi, długi czas.
GrandmasterB
2
Naprawdę wnikliwe. Programiści wydają się w większości zakładać, że pracują nad wysokimi inwestycjami i projektami generującymi duże zyski pieniężne, a odniesienie do Matrycy Wzrostu wyjaśnia, dlaczego tak naprawdę nie może tak być. Byłoby miło wiedzieć, czy projekty krów gotówkowych są dobre dla zaangażowanych pracowników - to ważna praca, ale czy niskie nakłady pieniężne zwykle oznaczają niskie wynagrodzenie na pracownika, czy tylko mniej pracowników? I z reguły nie będą to najnowocześniejsze technologie.
psr
1
@psr - z mojego doświadczenia wynika, że ​​może to być również dobre dla pracowników. W rzeczywistości widziałem lepsze oferty wynagrodzeń od bardziej stabilnych firm. Ale nigdy nie pracowałem dla prawdziwej organizacji typu green-field, ignorującej tempo spalania. „Niski nakład gotówkowy” jest terminem względnym i dotyczy bardziej kosztu alternatywnego niż czegokolwiek innego. Fundusze były zawsze dostępne dla projektów, które mogłyby wykazać odpowiedni zwrot z inwestycji. Niektóre lata ten próg ROI był wyższy niż inne z powodu wewnętrznej konkurencji o te fundusze.
5

Twój menedżer prawdopodobnie jest odporny na zmiany, ponieważ nie widzi, aby wartość (biznesowa) zmieniała praktyki. Firma nie widzi prawdziwego problemu, ponieważ ostatecznie cokolwiek zostanie zadane zespołowi programistycznemu, a skargi klientów nie trafią do ludzi, którym zależy i / lub mogą zrobić coś, aby zapewnić lepszy wynik. Albo to, albo firma zaczęła akceptować obecny stan rzeczy jako nieunikniony.

Jeśli zamierzasz zmienić praktyki programistyczne, musisz pokazać im, że obecna sytuacja nie jest nieunikniona. Jedyny sposób, w jaki zostaniesz usłyszany, to zbudowanie uzasadnienia biznesowego pokazującego, w jaki sposób obecny stan podnosi koszty produktu i powstrzymuje potencjał dochodu, biorąc pod uwagę inny stan rzeczy.

Aby zbudować to uzasadnienie biznesowe, musisz porozmawiać z kierownikiem produktu tego oprogramowania. Kierownik produktu jest osobą, która decyduje o priorytecie elementów do opracowania na podstawie wartości biznesowej, którą reprezentują. Menedżer produktu jest (powinien być) tym, który dostrzega korzyści i wartość biznesową szybszego tworzenia lepszego oprogramowania. (I mam nadzieję, że to nie to samo, co szef zespołu programistów).

W uzasadnieniu biznesowym należy zastanowić się, jaki wpływ na przychody firmy mają:

  • Funkcje, które nie są (jeszcze) zaimplementowane, które wygenerowałyby więcej klientów lub zatrzymałyby więcej klientów, gdyby zostały wdrożone.
  • Funkcje, które są niewłaściwie wdrażane, powodują niezadowolenie klientów i prowadzą do ich osłabienia.

W uzasadnieniu biznesowym należy również pokazać, w jaki sposób obecne praktyki programistyczne wpływają na szybkość i koszt opracowania bardzo potrzebnych funkcji:

  • Ile czasu zajmuje wprowadzenie nawet najprostszych zmian.
  • Ile błędów zostało wprowadzonych w wyniku opracowania nowych funkcji, zarówno w nowej funkcji, jak i w przypadku innych funkcji.
  • Ile czasu zajmuje naprawienie tych błędów, których nie można wydać na wdrożenie nowych funkcji.
  • Ile zgłoszeń do pomocy technicznej jest generowanych z powodu tych błędów i ile pracowników wsparcia musi wydać na te połączenia.

I oczywiście musi pokazać, w jaki sposób przyjęcie lepszych praktyk rozwojowych wpłynie na te liczby.

Prawdopodobnie stajesz przed koniecznością (poważnego) przepisania (głównych) części oprogramowania. Nawet jeśli tego nie zrobisz, to jak przeżyć od podstaw rewizję bez utraty zdrowia psychicznego, musisz przeczytać, jak podejść do tego rodzaju projektów.

Uwaga końcowa: jeśli menedżer produktu nie jest tym wszystkim zainteresowany, zgubiłeś się: wskocz na statek.

Marjan Venema
źródło
Dziękujemy za poświęcony czas i opinie. Zgadzam się, głównym powodem, dla którego najwyższe kierownictwo nie widzi tych problemów, jest to, o czym wspomniałeś: „skargi klientów nie trafiają do osób, które dbają i / lub mogą zrobić coś, aby zapewnić lepszy wynik”, czy programista może zrobić wszystko uniknąć tego?
kami
@kami: Poza tym: zacznij kompilować liczby i spraw, by zauważyli je ci, którym to zależy? Nie, niewiele, jeśli ograniczysz się do roli programisty. Jeśli chcesz, aby coś się zmieniło, musisz wyjść poza granice bycia programistą. Wyprostuj swoje liczby, przedstaw je najpierw swojemu przełożonemu i tylko tym powyżej / obok niego / niej, gdy nie podejmie żadnych działań. Nie omijaj jego głowy wynikami, zanim pozwolisz mu zabłysnąć swoją pracą. Pomoże to osiągnąć pożądane rezultaty.
Marjan Venema
Dzięki. Obecny menedżer „produktu” był programistą, który w jakiś sposób został menedżerem, a teraz jest kierownikiem ds. Rozwoju, kierownikiem produktu i kierownikiem projektu.
kami
@kami: niestety znany przepis na upadek spowodowany „zasadą Piotra: Dlaczego zawsze coś idzie nie tak” . Oryginalna książka: The Peter Principle
Marjan Venema
4

Myślę, że to naprawdę trudny problem bez bezpośredniego rozwiązania. Oto kilka pomysłów na to, co możesz spróbować:

Strach przed zmianą Na temat zmiany rzeczy na lepsze rozumiem, dlaczego zmieniają się obawy kierownictwa. Ludzie są przyzwyczajeni do rzeczy w określony sposób, a jeśli to zmienisz, użytkownicy zbuntują się (być może). Zmiana jest przerażającą rzeczą i zwykle wymaga dużo przemyślenia i przestudiowania przed jej wykonaniem. Potrzebne są dane, aby pokazać, że jest to lepsze i że użytkownicy tego chcą. Mówiąc o Gmailu, możesz pomyśleć o zrobieniu czegoś takiego jak „Google Labs”, w którym możesz włączyć / wyłączyć nowe funkcje, aby użytkownicy mogli spróbować. Następnie połącz gromadzenie danych wokół tego, aby utworzyć kopię zapasową zmian.

Zmiana procesu tworzenia oprogramowania Ponownie zmiana jest trudna, ludzie nie zmieniają się tylko dlatego, że mówisz, że jest lepszy sposób. Myślę, że w tym scenariuszu moją najlepszą rekomendacją jest dawanie przykładu. Rób rzeczy tak, jak chcesz, aby były zrobione i pokazuj ludziom, o ile lepiej. I to jest kluczowe, musisz znaleźć innych, którzy podzielają twoje myśli. Jeśli uda ci się zaangażować kilka osób, to znacznie pomoże twojej sprawie. Po pokazaniu niektórych wyników możesz zwrócić się do kierownictwa o rozszerzenie tych zmian. Uważam, że wysiłek odgórny i oddolny naprawdę pomaga w dokonywaniu zmian.

Również po stronie narzędzi firmy obawiają się ich aktualizacji, ponieważ kosztują pieniądze, a wyniki nowych narzędzi nie zawsze są mierzalne. Moim zaleceniem jest stworzenie własnych narzędzi. Jeśli stworzysz własny, zaoszczędzisz czas i wykonasz lepszą pracę. Mam nadzieję, że ludzie zaczną to zauważać, a potem też będą chcieli z nich korzystać.

Zmieniające się zarządzanie To trudne i nie jestem pewien, jak to zrobić, poza tym, że ktoś przynosi wyniki i ceni ich opinie. Gdy Twoja opinia zostanie doceniona, ludzie mogą zacząć słuchać lub nie.

Wreszcie pamiętaj, że zmiana jest trudna i wymaga czasu. Zawieś się tam i zacznij małe i buduj.

barrem23
źródło