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

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.

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ń.

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.

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 /

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.

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.

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.

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.

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.