Jak radzić sobie z zarządzaniem pchającymi starsze systemy?

14

Jestem obecnie na płatnym stażu i miałem za zadanie utrzymanie przestarzałego systemu, który został opracowany przez wielu programistów (w różnych okresach) w ciągu ostatnich 5 lat. Kierownictwo zgadza się, że „system jest objęty wsparciem życiowym” i otrzymuję dość regularną dostawę raportów o błędach od użytkowników końcowych aktualnie korzystających z systemu.

Kierownictwo chce teraz przedłużyć projekt o kolejny rok, a proces ten prawie potroił bazę użytkowników.

Jako stażysta (lub dowolne stanowisko podstawowe) w jaki sposób „odpychać”? Napisałem już raport wyrażający moje obawy, chociaż w otwartym dokumencie. Czy istnieje protokół lub typ dokumentu do sugerowania zmian? Czy jestem w stanie przedstawić sugestie, czy powinienem po prostu nadal wspierać stary system?

  • Aby to wyjaśnić, tworzenie oprogramowania nie jest podstawową działalnością mojej firmy. Jako takie nie istnieją wewnętrzne protokoły. Ponadto projekt nie ma żadnej formalnej dokumentacji ani dokumentów wymagań. Rozwój jest bardzo ad hoc.
James
źródło
6
Współczuję Twojemu problemowi. Niestety, nie ma łatwego sposobu na obejście tego i jestem pewien, że twoje pytanie zostało już zadane na wiele różnych sposobów. Jedną rzeczą, którą poleciłbym, jest unikanie pisania raportu z „otwartymi” obawami. Menedżerowie (zwłaszcza nietechniczni) NIENAWIDZĄ tego, czy mówią to wprost, czy nie. Jeśli na coś narzekasz, musisz przedstawić konkretne i praktyczne zalecenia dotyczące poprawy.
Angelo,
3
@James, format dokumentu w twoim kontekście jest całkowicie nieistotny. Liczy się to, że: 1) zidentyfikujesz zmiany, które musisz wprowadzić, 2) opisz konkretny plan ich wdrożenia oraz 3) przekonaj zaangażowanych osób, aby zgodziły się na ten plan. W środowisku, w którym rzeczy są „ad-hoc”, formalna struktura dokumentów nic nie znaczy.
Angelo,
7
O ile nie jest aktywny system zastępczy w trakcie aktywnego rozwoju, twierdzę, że obecny nie jest „na podtrzymaniu życia”. Zwłaszcza jeśli firma uwzględni to w planach na przyszłość.
TMN,
7
Od kiedy 5-letni system jest „dziedzictwem”?
Marjan Venema
1
@James - To nie jest definicja starszego systemu. Dziedzictwo jest definiowane przez dostępność (wyraźnie) nowszej lub bardziej wydajnej technologii, a nie przez awarię procesów wewnętrznych lub zatrzymanie personelu.
Jon Hopkins,

Odpowiedzi:

23

Jestem obecnie na płatnym stażu i miałem za zadanie utrzymanie przestarzałego systemu, który został opracowany przez wielu programistów (w różnych okresach) w ciągu ostatnich 5 lat. Kierownictwo zgadza się, że „system jest objęty wsparciem życiowym” i otrzymuję dość regularną dostawę raportów o błędach od użytkowników końcowych aktualnie korzystających z systemu.

System nie jest przestarzały, jeśli ludzie nadal go używają i wspiera działania biznesowe. Ponieważ wciąż jest używany, firma nie może go po prostu wyrzucić - należy go wspierać, dopóki nie będzie już potrzeby korzystania z systemu. Może to być zmiana celów biznesowych lub nowy system został opracowany, przetestowany i pomyślnie wdrożony u użytkowników końcowych.

Naprawdę 5 lat nie jest tak długie. Pracowałem z kodem, który miał już 10 lat. Jeśli nadal służy potrzebom użytkownika, po co go wyrzucać? To wyrzuca dużo pieniędzy wydanych na jego rozwój. Dopóki utrzymanie go z powodu rosnących kosztów lub wymagań nie zmieni się drastycznie, nie będzie uzasadnione, nie ma biznesowego powodu, aby je wyrzucać.

Kierownictwo chce teraz przedłużyć projekt o kolejny rok, a proces ten prawie potroił bazę użytkowników.

Jeśli kierownictwo mówi, że ten system jest „na całe życie”, dlaczego próbują go dalej wdrażać? Często czynności konserwacyjne są kontynuowane w dotychczasowym systemie, dopóki nie zostanie wymieniony, ale jeśli system jest wycofany z eksploatacji, zwykle nie jest wdrażany u większej liczby osób. Przedłużenie konserwacji to jedno, ale dodanie użytkowników, którzy polegają na systemie, to zupełnie inna sytuacja.

Dla mnie brzmi to tak, jakby to właściwie nie był koniec życia, ale raczej faza konserwacji i będzie tam, dopóki system nie spełni już potrzeb użytkowników.

Jako stażysta (lub dowolne stanowisko podstawowe) w jaki sposób „odpychać”? Napisałem już raport wyrażający moje obawy, chociaż w otwartym dokumencie. Czy istnieje protokół lub typ dokumentu do sugerowania zmian? Czy jestem w stanie przedstawić sugestie, czy powinienem po prostu nadal wspierać stary system?

Musisz nadal obsługiwać stary system. Później wspominasz, że oprogramowanie nie jest głównym przedmiotem działalności Twojej firmy. W takim środowisku zadaniem zespołów programistycznych jest wspieranie podstawowej działalności firmy. Jednak zespoły oprogramowania muszą również pamiętać o celach biznesowych.

Tymczasem przechwytuj swoje sugestie w sposób, który nie jest narzucający się. Wskaż inne technologie lub techniki, które można zintegrować z systemem lub zastosować, jeśli / kiedy zostanie utworzony nowy system i jego zalety / wady. To, jak to zrobisz, zależy od firmy, ale biorąc pod uwagę kilka późniejszych punktów, być może przydatne byłoby założenie wiki lub innej strony do współpracy.

W branży niezwiązanej z oprogramowaniem, oprogramowanie jest kosztem, a zespoły zajmujące się oprogramowaniem (szczególnie menedżerowie projektów / programów) powinny pracować nad jak najmniejszym kosztem budowy i utrzymania systemów oprogramowania, jednocześnie wspierając potrzeby użytkowników końcowych . Wyrzucanie oprogramowania, które (o ile mogę stwierdzić, w każdym razie z twojego postu) spełnia potrzeby użytkowników, jest sprzeczne z tym, co leży w najlepszym interesie zespołu programistów.

* Dla wyjaśnienia, tworzenie oprogramowania nie jest podstawową działalnością mojej firmy. Jako takie nie istnieją wewnętrzne protokoły. Ponadto projekt nie ma żadnej formalnej dokumentacji, żadnych dokumentów wymagań. Rozwój jest bardzo ad hoc.

Dla mnie to jest problem. Brak tworzenia dokumentacji, brak opracowywania specyfikacji i brak spójności prowadzi do wzrostu kosztów tworzenia oprogramowania. Praca nad rozwiązaniem tego problemu byłaby moim najwyższym priorytetem i zrobiłbym to, pracując nad takimi rzeczami jak standard kodowania, kontrola wersji, tworzenie samodokumentującego się kodu i dokumentów projektowych, śledzenie defektów i specyfikacja wymagań.

Thomas Owens
źródło
9
I've worked with code that was 10 years old before Co powiesz na około 25 lat :) Wciąż spełniałem potrzeby firmy i wykonałem niesamowitą robotę w tym, do czego została zaprojektowana, mimo że dotykanie kodu było tak przyjemne jak pływanie w arktyce.
wałek klonowy
@maple_shaft Nic nie ma 25 lat. Myślę, że najstarszy kod, jaki kiedykolwiek widziałem, miał około 10-15 lat. To nie jest przyjemne, ale użytkownik nie dba o czysty kod. Dbają o to, aby korzystać z oprogramowania, które robi to, czego potrzebują, w sposób, który pomaga ich firmie.
Thomas Owens
1
@James Nie bardzo. Jeśli jest to rozszerzenie oprogramowania lub wada, które wymaga pewnych zmian w istniejącym systemie, jest to śledzone w narzędziu do śledzenia defektów, w którym jest on traktowany priorytetowo i przypisywany. Jeśli jest to proces, metodologia lub zawiadomienie o przyszłym projekcie, które zostanie uchwycone przez projekt wykonalności, który prototypuje rozwiązanie lub notatkę inżynierską.
Thomas Owens
1
Pracuję nad 15-letnim systemem i sprawia mi to radość. Tak, są części, które można ulepszyć, ale mogą to być stare części lub części, które zostały napisane zaledwie sześć miesięcy temu. Jak u ludzi: wiek jest nieznaczny. Dbałość o rozwój oprogramowania i ilość długu technicznego powstałego podczas tego rozwoju decydują o tym, ile radości można z tego czerpać.
Marjan Venema
1
@James SRS jest techniczny. Jeśli zajmujesz się bezpośrednio zarządzaniem, a tworzenie oprogramowania nie jest ich główną działalnością, będziesz musiał przedstawić to w kategoriach biznesowych. Ponieważ nie ma istniejącej dokumentacji projektowej i tak dalej, zacznę od uzasadnienia biznesowego lub planu projektu lub analizy opcji w celu ponownego zaprojektowania przed jakimkolwiek SRS. Menedżerowie i biznes rozumieją tylko koszty. Kompletne przepisanie może być obarczona trudności, więc uważaj.
Jason S
7

Napisałem już raport wyrażający moje obawy

Dobry. Chodzi o zakres tego, co możesz zrobić jako stażysta. Na przyszłość, pisząc takie raporty, podkreślam przedstawianie twardych faktów w sposób bezstronny, profesjonalny, pozbawiony emocjonalnych uprzedzeń. Nie wiesz, kto przeczyta raport, być może ktoś, kto spowodował niektóre z opisanych przez Ciebie problemów lub podjął decyzje, które doprowadziły do ​​tych problemów. Cokolwiek innego niż zimne fakty mogą być traktowane przez takich ludzi jako afront lub przestępstwo i sprawi, że nie będą cię lubić i być może nie będą traktować tego poważnie.

Kierownictwo chce teraz przedłużyć projekt o kolejny rok, a proces ten prawie potroił bazę użytkowników

Należy pamiętać, że takie decyzje biznesowe są podejmowane, ponieważ starają się podejmować odpowiednie środki, które mają dla nich dostępne. Jestem pewien, że kierownictwo prawdopodobnie zdaje sobie sprawę z problemów ze starszym oprogramowaniem i prawdopodobnie wie o skargach użytkowników, ale czy mają dostępne zasoby programistyczne do obsługi refaktoryzacji lub przepisania?

Przez większość czasu tak nie jest, szczególnie jeśli oprogramowanie nie jest chlebem powszednim firmy, a jakość i zadowolenie użytkownika z oprogramowania nie wpłynie bezpośrednio na wynik finansowy. Podejmowanie tego rodzaju decyzji jest czasem powodem, dla którego bycie menedżerem jest do kitu, ponieważ często znajdujesz się w sytuacji przegranej bez względu na to, co robisz.

utrzymywanie przestarzałego systemu, który został opracowany przez wielu programistów (w różnych momentach) w ciągu ostatnich 5 lat

Podczas całego projektu popełniono błędy, które doprowadziły go do tego momentu. Brak solidnego wkładu użytkownika lub wymagań, brak właściwego zarządzania produktem i kontroli zmian w celu zarządzania zmieniającymi się wymaganiami i potrzebami oraz brak odpowiednich zasobów technicznych do wdrożenia spowodowały problemy, jakie istnieją obecnie. Nie wiem jednak, czy przestarzałe to właściwe słowo. Czy podstawowa technologia oparta jest na nieobsługiwanych ramach i technologiach, czy też nie jest to najnowocześniejsza lub idealna technologia?

Jako stażysta (lub dowolne stanowisko podstawowe) w jaki sposób „odpychać”?

Jesteś w pozycji o najmniejszej mocy i jesteś na to tymczasowy. Nie ma znaczenia, czy masz rację, nie spodziewałbym się, że stażysta kiedykolwiek mnie „odepchnie”. Oczekuję, że będą się uczyć, dyskutować o problemach tak, jak je widzą, i wykonywać polecenia. O to chodzi. Po wydaniu zamówienia oczekuję, że zostanie ono zrealizowane najlepiej jak potrafią, ponieważ czas dyskusji dobiegł końca.

wałek klonowy
źródło
Być może użycie terminu „dziedzictwo” było nieprawidłowe. Obecnie technologią napędzającą system jest VBA i klasyczna ASP. Baza kodu została stworzona w przeszłości przez kilku rotujących stażystów. Wikipedia identyfikuje starszy system jako taki, który nie jest już rozumiany, i że takie sytuacje występują, gdy system nie jest udokumentowany i / lub pierwotni twórcy odeszli. Dodatkowo „odpychanie” jest cytowane, ponieważ mam osobiste motto, aby „nigdy nie być zadowolonym ze przeciętności” i jako takie nie mogą znieść siedzenia z tyłu i wyrażania obaw. Wydaje mi się, że nie jestem pomocny
James
@James Dobrze jest wyrazić obawy, ale zrób to raz, zrób to całkowicie, przedstaw realną alternatywę, a następnie pozostaw to. Jeśli wypowiesz się na ten sam temat więcej niż jeden raz, będziesz postrzegany jako skąpiec, a skomlenie nie będzie pomocne. Jeśli tego nie rozumiesz, a nikt w domu tak naprawdę nie rozumie go pod względem technicznym, to prawda, że ​​masz rację.
wałek klonowy
7
James, być może nigdy nie jesteś zadowolony z przeciętności, ale dzięki tej wymianie masz wrażenie, że nie jesteś dobry na szerszym obrazie, w jaki sposób oprogramowanie wspiera biznes i jak priorytety biznesowe różnią się od twojego.
temptar
2
„Wikipedia identyfikuje starszy system jako taki, który nie jest już rozumiany”. Cóż, jeśli go zrozumiecie i udokumentujecie, więc zrozumiecie, to nie będzie to już starszy system.
DJClayworth
2
„nigdy nie zadowalaj się przeciętnością” to dobre motto, ale dotyczy tylko rzeczy, które możesz kontrolować. Jeśli weźmiesz mierną bazę kodów i zamienisz ją w dobrze udokumentowaną, łatwą w utrzymaniu bazę kodów, to doskonała praca, z której powinieneś być dumny.
DJClayworth,
5

Jesteś stażystą. Wątpię bardzo, czy zdajesz sobie sprawę z codziennych imperatywów biznesowych, a jak zauważyli inni, pięcioletnia baza kodów nie jest tak stara.

Decyzje dotyczące zastąpienia starszych systemów nie zawsze są technicznie uzasadnione; są napędzane przez zmieniające się wymagania biznesowe. Wkładem w te mogą być trudności związane z utrzymaniem; ale na koniec dnia musisz uznać, że Twoje stanowisko niekoniecznie oznacza, że ​​masz całą dostępną i wymaganą wiedzę. Chciałbym posunąć się nawet do stwierdzenia, że ​​faktycznie masz bardzo mało wymaganej wiedzy, aby zadzwonić na temat tego, co jest obecnie najlepszym posunięciem.

Moja rada jest następująca: ucz się na podstawie doświadczenia i przestań zakładać, że twoja wiedza przebija wiedzę ludzi, którzy muszą prowadzić działalność na co dzień.

Twoim zadaniem jest utrzymywanie działania systemu, a nie sugerowanie nowego, błyszczącego zamiennika.

Wydaje mi się, że wielu młodych programistów nie zdaje sobie sprawy, że utrzymanie starszych systemów jest większą częścią pracy programistycznej niż projektowanie błyszczących nowych systemów /

kuszenie
źródło
Uważam, że masz rację twierdząc, że nie rozumiem szerszego obrazu, ponieważ nie jestem zaznajomiony z narzutami związanymi z wewnętrznym tworzeniem oprogramowania. Edukacja, z którą miałem do tej pory styczność, dotyczyła przede wszystkim procesu formalnego, a przynajmniej tam, gdzie głównym przedmiotem działalności jest tworzenie oprogramowania
James
4

Nie odpychaj się. Jedyne, co powinieneś zrobić, to wyrazić swoje obawy w jasny, zwięzły sposób. Faktem jest, że większość firm, w których będziesz pracować w przyszłości, będzie miała starsze systemy. Te starsze systemy należy utrzymać, ponieważ w wielu przypadkach ich wymiana jest zbyt droga.

W wielu przypadkach możesz nawet mieć najlepsze intencje zastąpienia obecnego systemu lepszym systemem, jednak możesz po prostu wprowadzić nowe i różne błędy ... kiedy odejdziesz, system szybko zmieni się w starszy system, a firma będzie być w tym samym miejscu co przedtem. Nic nie jest przestarzałe, dopóki nie będzie już spełniało funkcji serwera lub nie będzie całkowicie niezgodne z nowoczesnymi systemami. Moja firma ma ponad 20-letni system, który właśnie konwertujemy na ASP.NET. System nadal działa, ale wsparcie dla starej technologii maleje, a jej obsługa w nowoczesnych przeglądarkach internetowych jest coraz bardziej czasochłonna.

Co możesz zrobić:

Zostaw rzeczy czystsze

Kiedy utrzymujesz coś, zostaw to czystsze niż na początku. zrób poprawkę, ale także posprzątaj rzeczy, więc następnym razem, gdy ktoś będzie musiał dokonać modyfikacji, łatwiej to zrozumieć.

Utwórz dokumentację

Jeśli problemem jest brak dokumentacji, utwórz dokumentację. Kiedy pracujesz nad określoną częścią systemu, udokumentuj ją.

Spraw, by było mniej bolesne

Jak już powiedziałem, możesz wyrazić swoje obawy, ale najlepiej jest po prostu pracować sumiennie nad systemem i sprawić, że lepiej będzie pracować dla tych, którzy cię ścigają. Napraw błędy poprawnie. Dokument. Rozprasza zapach. Zrób to lepiej. A kiedy to robicie, dajcie znać swoim przełożonym. Powiedz im, że robisz X, Y i Z, aby usprawnić proces rozwoju. To buduje wiarygodność i na dłuższą metę pomoże Tobie i Twojej firmie bardziej niż cokolwiek innego.

Mike Cellini
źródło
1
Jedną z najważniejszych rzeczy, które można wykonać jako X, Y lub Z, jest napisanie testów jednostkowych. Posiadanie testów sprawia, że ​​praca ze starszym kodem, który może w dowolnym momencie ulec uszkodzeniu, jest znacznie mniej stresująca.
Kevin Vermeer
3

NIE !!! To jest WIELKA okazja!

Jesteś stażem do nauki! Ten projekt to prawdziwy świat.

Masz szczęście, że to masz. To, że nie masz kwalifikacji, nie jest twoim zmartwieniem. (Jeśli \ kiedy kierownictwo to zrozumie, wiele zyskasz)

Zostaniesz zakwalifikowany, kiedy skończysz ten staż, i to jest świetna wiadomość.

PS: Twórz kopie zapasowe z pobożności religijnej, upewnij się, że WSZYSTKIE, co robisz, można wycofać. Zacznij od problemów, które są „łatwymi rozwiązaniami”, ale stanowią duże problemy dla użytkowników. Rób kroki dla dzieci.

Kretynowie
źródło
Inną rzeczą, dla której staże są świetne, jest ustalenie, czy chcesz pracować dla firmy i (dla nich), czy chcą, abyś pracował dla nich. Jest to sytuacja znacznie lepsza niż w przypadku, gdy PO został zatrudniony jako pracownik zatrudniony w pełnym wymiarze godzin i obawiał się utrzymania pierwszej pracy lub szybkiego odejścia.
Kevin Vermeer
3

Myślę, że w bardzo teoretycznym sensie - nie ma czegoś takiego, jak system Legacy . Mam bardzo stary telefon (starszy system), a obecnie są dobre telefony z Androidem (nowoczesne platformy), ale mój telefon działa i robi to, czego potrzebuję. Dlaczego mam to wyrzucić?

Wszystkie systemy, które dziś nazywacie „starszymi”, były pewnego dnia najnowocześniejsze. To tylko czas, którego potrzebujemy. Ponadto, gdy istnieje spora praca, nie jest tak, że ponowne wykonywanie wszystkich rzeczy ponownie na nowoczesnych platformach oznacza, że ​​będzie ona automatycznie wolna od błędów (lub bez bólu).

Oto, co polecam powinieneś zrobić:

  1. Najpierw porzuć niechęć do „starszego systemu”. Dzięki temu będziesz bardzo przeciwny do produktywnego.

  2. Rozpocznij dokumentowanie tego, co teraz robisz i co myślisz. Chociaż krok po kroku. Nie ma po prostu lepszego czasu na zrobienie dokumentacji niż ta, w której zdajesz sobie sprawę, że jej potrzebujesz.

  3. Zamiast próbować odepchnąć dalszy rozwój „starszego systemu” - spróbuj zdefiniować ścieżkę dla jego płynnego wyjścia. Postaraj się przekonać kierownictwo, że nowszy program, który można odizolować, można wykonać krok po kroku w nowszych platformach bez naruszania interoperacyjności ze starymi systemami. Powoli (a będzie to naprawdę powoli) wraz z rozwojem sytuacji, potrzeba utrzymania dotychczasowego systemu zniknie. To jedyny sposób, aby pożegnać się ze starym systemem.

Dipan.

Dipan Mehta
źródło
2

Prawda jest taka, że ​​nikt nie daje stażystom pracy, którą chcą wykonywać. Kiedy jesteś młodszą osobą, dostajesz najmniej ekscytującą pracę. Jak dobrze sobie z tym radzisz, wiele mówi to organizacji, czy może ona zaufać, że wykonasz więcej ekscytującej pracy.

Oto więc bezcenna okazja, aby pokazać, że możesz dostarczyć, wykonując poprawki błędów, które możesz refaktoryzować, sprawiając, że każda część dotkniętego kodu będzie nieco lepsza, że ​​możesz tworzyć testy jednostkowe, zaczynając od tworzenia ich dla tego systemu i że możesz udokumentować, tworząc dokumentację dla następnej biednej duszy, która utknęła w tym systemie. Daje również możliwość pokazania, że ​​możesz skutecznie radzić sobie z użytkownikami (aby uzyskać więcej informacji na temat zgłaszanych błędów) i zaspokoić ich potrzeby. Jeśli projekt nie jest teraz pod kontrolą źródła, umieść go tam, a jeśli błędy nie są śledzone w narzędziu do śledzenia błędów, uruchom jeden z nich. Tego rodzaju działania pokażą Ci, jak profesjonalnie pracować.

Lub możesz pójść przeciwną ścieżką i po prostu suka o tym, jak zły jest projekt i jak fajnie byłoby go zastąpić. W takim przypadku prawie na pewno nie otrzymasz pracy w tej firmie po odbyciu stażu.

HLGEM
źródło
1

Prawdopodobnie nie masz wystarczających informacji, aby ustalić, czy opłacalne jest wyjechanie na kolejny rok, czy nie. Interesujące byłoby zrozumienie firmy i tego, dlaczego dodają użytkowników. Wydaje się, że może nastąpić pewien wzrost i po prostu nie stać ich na wycofanie się pod względem finansowym lub pod pewnymi ograniczeniami czasowymi, aby zbudować inną aplikację. Budowanie nowej aplikacji i tak rzadko jest najlepszym wyborem. 5 lat nie jest aż tak stare, chyba że na początku zbudowano je na starej technologii.

JeffO
źródło