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
Odpowiedzi:
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:
źródło
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ć.
źródło
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.
Jak zauważyłeś, istnieje kilka zalet bycia w projekcie krowy gotówkowej.
I, jak zauważyłeś, są pewne wady tych projektów.
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
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ą:
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:
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.
źródło
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.
źródło