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